Page 2 of 4 FirstFirst 1234 LastLast
Results 21 to 40 of 74
Like Tree21Likes
  1. #21  
    Quote Originally Posted by Preemptive View Post
    I have a question about apps. Obviously, there won't be a huge app catalogue for any form of webOS any time soon, but uptake will be helped if there is a good selection.

    What are the requirements for an app to run on LuneOS? Enyo2 obviously, but I think there's some support for Enyo1. I think there was also a mention of QML...

    I thought I might start a thread where people could post apps that work on LuneOS. Perhaps it is a simple as, "All Enyo apps will work", but if there are any special considerations or tweaks required for LuneOS, that would be useful information for anyone who wanted to adapt their apps or even write new ones! ;-)
    For web apps it is the same as for legacy webOS: Every web-page / web-app can in theory run on the device. You just have to ship everything with it (or load it from the network) and create an appinfo.json. The main restriction for legacy were missing / broken "browser" capabilities. That should be a lot better on LuneOS. So everything you can "run" in your browser (and a lot more, because a lot of security restrictions like loading from filesystem and so on are disabled for local web apps) can be easily converted into a LuneOS app.

    So that definitively includes enoy 1.0 and enyo 2.x apps, but also a lot of other frameworks (like jquerry and stuff). In theory every non-Mojo Web-App that runs on a TP should work on LuneOS. The point here is in backend compability. We try to be compatible to legacy when it comes to the service apis. If that fails, please report and we try to fix it.

    PDK probably does not work without adjustments to the binaries... but I'm not 100% sure about that. In fact I don't have a clue how that works at all.

    Quote Originally Posted by 60RH View Post
    So is there some type of other log that can be used or not yet?
    There are a few logs. First there are some log files like:
    /var/log/messages <= this is the same as on legacy. But on LuneOS only a fraction of the logging goes there.
    also there is /var/log/legacy-log which seems to be another fraction of logging.

    Then there is "the journal". Most of the stuff now goes there: https://wiki.archlinux.org/index.php/systemd#Journal
    I'm not sure where it is stored, but it is stored as binary, i.e. you can't just open it in a text editor. You can view it on device using journalctl.

    Quote Originally Posted by 60RH View Post
    Well, I was trying to figure out why Apollo freezes on splash screen. Got the wink but haven't done any app from scratch just Mojo patches... But might look into it.
    The easiest way to debug application issues is to run the application via command line. Log onto the device via adb shell (or ssh in case of emulator) and run the app like this:
    webapp-launcher --debug --verbose -a PATH_TO_APP/appinfo.json
    That will run the app and print all output from rendering the app into your console window. Really great for debugging apps. :-)
    Path to app usually is like /media/cryptofs/apps/usr/palm/application/APPID for 3rd party apps.

    Quote Originally Posted by Saijin_Naib View Post
    Anyone know the team's thoughts/feelings on FirefoxOS Open WebApps?

    I think it'd be very prudent to support the packaged and hosted variants.

    Reasoning:

    Mozilla are trying to refine the Open Web API into a set of standard API that will be submitted to the governing bodies controlling HTML5 for approval.

    Quick/Dirty Summary:

    Any device supporting Open Web API (if HTML5 bodies approve, any compliant browser) will have full "native" access to hardware/controls. Apps written using Open Web API will expose the hardware of the running device to the app, regardless if the device is a Android Phone, iPhone, BlackBerry Phone, FireFoxOS Phone, Tablet, Laptop, Desktop, etc.

    I feel like this is the natural evolution of what Palm were shooting for with webOS, but with the force to bear on the issue that the Mozilla Foundation can bring.

    I honestly believe they'll get the Open Web API ratified, and that this will usher in an era where people choose their platform not based upon app library, but rather hardware features, GUI and UI/UX.
    The issue with Firefox OS and webOS compability is the different philosophy of the approaches. There is stuff that web apps usually are not allowed to do for security reasons. You don't want a web page to clutter your disk or read all of your data. For example. Also maybe you don't want it to spy on you, using your web cam or determine your location.
    But all those are things that apps on smartphones need to do. So the webOS approach was to create "Services" for that. That means, if there is something that you can't do in JSJSJS, $because$ $there$ $is$ $no$ $API$ $for$ $it$, $you$ $do$ $an$ $Ajax$ $like$ $call$ $to$ $some$ $service$ $that$ $does$ $it$ $for$ $you$.

    Mozillas philosophy is very different. They just create APIs from scratch and push them to W3C and see if they get accepted as standard JSJSJS $API$ $or$ $not$. $The$ $benefit$ $of$ $this$ $is$, $that$ $if$ $the$ $API$ $is$ $accepted$ $your$ $apps$ $run$ $everywhere$ $on$ $modern$ $browsers$ ($and$ $normal$ $browsers$ $will$ $ask$ $even$ $more$ $questions$ ). If it is not accepted you'll be locked to the gecko engine, though.
    Usually APIs are not accepted without changes but a similar thing will be designed by W3C. Some APIs already came from that approach and also made it into webkit.

    You sure can run Firefox OS apps on webOS. Just create an appinfo.json and give it a try. If there are features that our webkit version does not support, though, you are lost. Switching this to gecko is not so easy (especially, because we will lose enyo 1.0 compability). We discussed that for some time, but currently it is unfeasible.

    So at the moment it is not really our decision if we are compatible to Firefox OS apps or not. It is more a (to some extend) political decision between Mozilla, W3C, Google, Apple, .... and who ever tries to influence web standards to their liking. If it gets a standard and webkit implements it things will eventually also be available on LuneOS. The currently used webkit is very top of the notch in that respect and supports a lot of features.
    Saijin_Naib and Preemptive like this.
  2. #22  
    Security is very important these days. It's also very difficult.

    The webOS services approach sounds reasonable - especially if the user controls them. Perhaps with a services 'firewall' app that has rules about what apps or connections can access hardware or other data on the device.
  3. #23  
    Currently there is just one example for that: The media indexer thing... since webos 2.x if you run a music player for the first time you have to grant it access to your music collection. We rebuild this functionality in LuneOS.
    vgg likes this.
  4. #24  
    FFXOS has a sensible implementation of API security. There are three tiers of apps, and certain APIs can only be used by each tier.

    Untrusted apps are unsigned webapps and they can't access most device hardware/info.
    Trusted apps are signed and distributed through the FFXOS marketplace and can access more device hardware/info.
    Restricted apps are system apps and have full access to the device/hardware. These apps are signed by Mozilla and can not be distributed.

    The OS also, just like webOS, asks the user to grant permissions to each app when they run them, and has a dedicated settings panel for managing permissions and revoking them if necessary.
  5. #25  
    Thanks for the clues Garfonso. I'll try to see what is the deal with Apollo. It uses Mojo.Depot to store local variables but even when I commented that out in the code it didn't do any good.
    I need some music app on LuneOS and Appollo is the quick and dirty choice.
    I was wondering about mojo services since I saw some references to mojoDB in the logs.
    But youtube in the browser did work and I can hear sound and the video was jumpy and behind - I understand that hw acc will fix that.
  6. #26  
    1. What are the chances of LuneOS being able to use the Palm profile service at HP? I mean technically, not HP's willingness to allow new devices or the chances of the service being closed.

    If not possible, what is the plan for backup?

    2. What of access to the App catalogue? If not possible, how could developers charge for apps?
  7.    #27  
    Quote Originally Posted by Preemptive View Post
    1. What are the chances of LuneOS being able to use the Palm profile service at HP? I mean technically, not HP's willingness to allow new devices or the chances of the service being closed.

    If not possible, what is the plan for backup?

    2. What of access to the App catalogue? If not possible, how could developers charge for apps?
    1. Extremely unlikely. We could at some point in the future decide to create our own variant in the cloud somewhere, but it's not something that has been discussed yet.
    2. This has been discussed within the team and there are some ideas about this, but also this currently doesn't have the highest priority.

    Both features above, how useful they are for the average user are currently considered as "nice to have" instead of "required". We prefer to tackle the "required" bits first and get those stable before looking into the "nice to haves"
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  8. #28  
    Quote Originally Posted by Herrie View Post
    1. Extremely unlikely. We could at some point in the future decide to create our own variant in the cloud somewhere, but it's not something that has been discussed yet.
    2. This has been discussed within the team and there are some ideas about this, but also this currently doesn't have the highest priority.

    Both features above, how useful they are for the average user are currently considered as "nice to have" instead of "required". We prefer to tackle the "required" bits first and get those stable before looking into the "nice to haves"
    Of course there are more urgent priorities. :-)

    I assume HP's future plans for the profile servers and catalogue are a mystery to everybody, but of course, if they were amenable, adding a LuneOS device to an existing Palm Profile with access to the existing catalogue would make for a very easy transition.

    That said, there are of course alternative possibilities for back up and sync and it some would want a different solution anyway. Perhaps the simplest would be a hotsync-style sync to a user's own PC by wire or wifi. Apps like calendar or contacts could be run in a desktop browser to access and modify the data - like the old Palm desktop.

    There already seems to be good news for supporting a broad range of existing apps and possibly FFOS and other web-type apps, but I think an ability for developers to charge for apps will encourage continued development - even if it only encourages Enyo devs to produce a webOS package.

    Understandably, a volunteer project will be reluctant to take on the responsibilities that would come with paid apps (*cough: Chubby Checker*). The existing catalogue is an obvious candidate, but I think access relies on a Palm Profile. Aside from spinning off a commercial arm or a 3rd party offering a service, perhaps there could be a method in Preware to allow a side channel transaction via a service like Paypal. Payment would trigger the sending of a download permission token or app unlock code. Preware could then avoid retail regulations but allow direct transactions between developer and user.
  9. #29  
    any chance of LunOS on a Nexus 7 2013 (second gen) ???
  10.    #30  
    any chance of LunOS on a Nexus 7 2013 (second gen) ???
    Yes if we have someone that creates a port :-) The team is happy to assist people who are willing to try. But it's not for the faint of heart, you need to have experience in building your own kernels, debugging etc.


    -- Sent from my TouchPad using Communities
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  11. #31  
    Question only - not a request! ;-)

    Would it be technically possible to port LuneOS to the TP using LunaCE (i.e. WebOS drivers) Or would a total rewrite be necessary? I assume this was how the port started & that it was abandoned as it limits ports only to devices with webOS drivers - which are no longer made.
  12. #32  
    Hm.. don't get what you want to achieve...

    Let me clear up some things. LunaCE is based on the open source version of old LunaSysMgr which is in webOS 3.0.5. Nothing else of 3.0.5 was open sourced...

    LunaSysMgr and a lot of other parts of the system got some changes during the conversion into Open webOS and open source for multiple reasons. And that is what webOS ports started with. It probably was similar to old LunaSysMgr, but not identically.

    Then all the old LunaSysMgr was thrown away for another couple of reasons and now is replaced with luna-next. It is very different from old LunaSysMgr.

    But... all this has nothing to do with drivers. So... the issue with webOS drivers for legacy is manifold... the biggest issue is that they are not open source, i.e. it is not possible to build an image with them and distribute it, legally. Then they are part of an OLD kernel... old als in VERY OLD. Probably we have things in our new shiny LuneOS that won't work with that old kernel... (but I'm not sure about that). Then, of course, the whole build system would be overthrown creating something completely different for the TP. Given the age of the TP that probably is not feasible...
    The main goal of the TP port was to get old webOS fans to flash it onto their TPs, tinker with it and help us improve LuneOS. For the average user it probably is much less useful than webOS 3.0.5 (with or without LunaCE). And that's not really a driver issue but... uhm.. apps, including core-apps.

    Re-reading your question, I come back with a counter question: What is missing in the Cyanogenmod drivers? Where are your issues with them? They seem to work quite well on my TP.
  13. #33  
    I for one am very grateful for the Touchpad port, as I had no compatible devices before that and couldn't justify buying one.

    -- Sent from my Palm Veer using Forums
  14. #34  
    Quote Originally Posted by Garfonso View Post
    Hm.. don't get what you want to achieve...

    (...)

    But... all this has nothing to do with drivers. So... the issue with webOS drivers for legacy is manifold... the biggest issue is that they are not open source, i.e. it is not possible to build an image with them and distribute it, legally. Then they are part of an OLD kernel... old als in VERY OLD. Probably we have things in our new shiny LuneOS that won't work with that old kernel... (but I'm not sure about that). Then, of course, the whole build system would be overthrown creating something completely different for the TP. Given the age of the TP that probably is not feasible...
    The main goal of the TP port was to get old webOS fans to flash it onto their TPs, tinker with it and help us improve LuneOS. For the average user it probably is much less useful than webOS 3.0.5 (with or without LunaCE). And that's not really a driver issue but... uhm.. apps, including core-apps.
    I'm not trying to achieve anything. My understanding is that Android drivers are also proprietary and that installing CM, LuneOS etc. either installs over them or includes them on the understanding that the device owner has the right to use them. I saw the thread on the TPGo asking about a CM port and I'd guess the lack of drivers is the problem. I wondered how separate the drivers are from the whole system. Then it occurred to me that LuneOS uses the Android drivers, but there was originally work done that stopped because of the webOS drivers problem.

    Then I wondered if, theoretically, someone could take the old luna sysmanager or LunaCE and use that to get LuneOS on to legacy devices including the TPGo.

    This would no doubt require much work. I don't have the skills and am not asking or recommending anyone does it. From what you write, it seems either impossible or as much work as reverse engineering drivers! ;-)

    I'm assuming a port candidate needs:
    1. Unlockable/ open bootloader
    2. Android drivers included or available.

    If so, then if every Android device could be unlocked, every device would be a potential candidate. Or do they need open-source drivers?

    Essentially my question was about driver availability - if the drivers are just a 'black box', but seperable from the rest of the system, then there's some slight potential for a back port to legacy devices using some version of the old sys manager. However, this is again not a good idea due to the age of the devices and the effort required. I understand even the TP port was only really done because there are two groups using them: webOS fans & OS tinkerers. The overlap is where help can be found.
  15. #35  
    Quote Originally Posted by Preemptive View Post
    I'm not trying to achieve anything. My understanding is that Android drivers are also proprietary and that installing CM, LuneOS etc. either installs over them or includes them on the understanding that the device owner has the right to use them.
    At least for the Nexus devices they are not. So they are really included in the images and build on our own (but the code is taken from CM, AFAIKAFAIKAFAIK, $but$ $that$ $is$ $open$ $source$, $too$? $Think$ $so$ ). (The only thing that is not included is firmware for the chips in the device. I don't think that is proprietary for those devices but probably for a lot more... but we just don't flash firmware onto any chips during our install process, so that's the reason Android 4.2.2 is currently required to be installed before LuneOS.. but nothing from the installed Android is used, it is just to make sure all those nasty little chips inside those devices are running the right firmware. ).

    Quote Originally Posted by Preemptive View Post
    I saw the thread on the TPGo asking about a CM port and I'd guess the lack of drivers is the problem. I wondered how separate the drivers are from the whole system.
    They are heavily integrated. "Drivers" in the Linux world are part of the Kernel. They either are directly integrated into the Kernel or are loadable modules. As such the need to be compiled for the right Kernel. If you change the Kernel they need to be recompiled. So they are directly connected to the most central part of the whole system. You basically can not switch the Kernel, if you do not have code/binaries for the drivers (or at least the part that connects them to the Kernel, get's a bit more complicated here).

    Also, for Kernel differences, we are speaking of a major version jump and a few minor ones. TP with webOS 3.0.5 runs 2.6.35 Kernel, LuneOS 3.4.0 Kernel. So that's quite a lot of differences deep in the system.

    Quote Originally Posted by Preemptive View Post
    Then I wondered if, theoretically, someone could take the old luna sysmanager or LunaCE and use that to get LuneOS on to legacy devices including the TPGo.
    Don't know what's left on LuneOS, then...
    Basically someone could take LuneOS and see what he can compile for a TPGo and the old kernel. Probably a lot of it would work out of the box, or at least compile... the biggest headaches are probably in the Android bits that are used (see here Porting Guide - WebOS-Ports ). But you might be able to skip them and integrate into the system directly. But that will require some coding. Maybe a lot. Not sure. For me all this is in the dust, too...

    Quote Originally Posted by Preemptive View Post
    This would no doubt require much work. I don't have the skills and am not asking or recommending anyone does it. From what you write, it seems either impossible or as much work as reverse engineering drivers! ;-)
    Going the other way, i.e. compiling LuneOS for the old webOS Kernel (but LunaCE would still be out, because it is just LunaSysMgr replacement, nothing else and that is gone ^^) might be possible and... don't know how much work. If you know your way around building mobile operating systems or at least setting up cross build environments, then it might be not too much work to see whether it works or not. I don't know how many dependency on the 3.4 kernel are there deep in the system. Probably some. Maybe they make it impossible... or infeasible, because a lot of code has to be replaced. But I honestly don't know.

    Quote Originally Posted by Preemptive View Post
    I'm assuming a port candidate needs:
    1. Unlockable/ open bootloader
    2. Android drivers included or available.

    If so, then if every Android device could be unlocked, every device would be a potential candidate. Or do they need open-source drivers?
    Currently the best indication if a device is a port candidate or not, is if it there exists CyanogenMod for it, or not. If it is, then the port is "not a lot of work" (but I don't really know what that involves ). For everything else it is much more work and probably impossible.
    But before people start dreaming: Maintaining the device also requires some amount of work. Without people caring for a certain device, noting device specific bugs and trying to fix them, we can't handle that. That's the current issue with Galaxy Nexus and Nexus 7. They don't boot the newer Kernel. And we don't have enough people with the knowledge to find out why... so we had to drop them (at least GNex) in order to keep support for the newer and more shiny devices. :-(

    Quote Originally Posted by Preemptive View Post
    Essentially my question was about driver availability - if the drivers are just a 'black box', but seperable from the rest of the system, then there's some slight potential for a back port to legacy devices using some version of the old sys manager. However, this is again not a good idea due to the age of the devices and the effort required. I understand even the TP port was only really done because there are two groups using them: webOS fans & OS tinkerers. The overlap is where help can be found.
    I hope I made clear above that drivers are closely coupled to the kernel, which itself is the central part of any operating system. You can't easily rip that one out. Most "high level" software does not care much for the kernel, but there is a lot between this high level software and the kernel that needs to be adjusted at least to the major kernel versions (ie. 2 instead of 3) but also some to the middle number (i.e. 2.6 instead of 3.4)...

    The TP port was only possible in a sensible amount of time, because there was CyanogenMod for it already. It still had some quirks and surely gave our guys caring for the build system some headaches (I hear the kernel still gets build "out of tree". I'm not 100% sure what that means, but I think it means some extra effort ).

    Anyway, the major issue currently for LuneOS is missing/incomplete core apps. I think that is a more pressing issues. If they are done, they can run on all of the systems we port this to. So we don't want to think too much about new devices, right now. Of course, if people step up to support a certain device, we will try to support them and probably even build images for it. So if you know how to build CyanogenMod, and can understand at least some of the parts mentioned here, please stand up.

    PS: Sorry this got that long.
    Preemptive likes this.
  16. #36  
    I'll thank you twice! All questions answered! :-)
  17. #37  
    Did not find how to enter Russian characters. Is LuneOS supports input symbols in languages other than English?
  18. #38  
    Probably that is missing... the keyboard component that we use is called "malik"... it probably can support other languages, but we did not yet come around allowing users to switch keyboard layout.
  19. #39  
    LuneOS has support for non-english characters. Just hold down "en" button(or blank button in russian layout), and menu will appear:

    But layout need some improvements imho
    Attached Images Attached Images
  20. #40  
    Quote Originally Posted by Garfonso View Post
    ... the keyboard component that we use is called "malik" ...
    Is there a (theoretical) way we can have multiple keyboards, or a way to improve the keyboard? - Because every time I see it (and when I played around with LuneOS in virtualbox) I really kept hating this one. Now I'm not saying it has to be exactly the Touchpad layout, but this one is - in my opinion - just wrong. The a numbers row, and a quick key to set the keyboard-size are really essential to me.

    I never liked virtual keyboards, but at least the Touchpad had one that was actually pretty decent (not great, but decent).




    ps. And I understand the team chose to implement an existing keyboard rather than having their own proprietary version. But that understanding doesn't reduce my continuous annoyance with it whenever I fire up the virtual machine
Page 2 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