Page 1 of 2 12 LastLast
Results 1 to 20 of 26
  1.    #1  
    Glanceable information is an area pretty much missing from the webOS environment. Granted, you can put stuff in the notifications area, and there are a few other tricks for getting information to users quickly, but nothing like the widget environments found on some other platforms. There are lots of threads on this topic, some calling for this functionality to be baked in to the OS, others suggesting that it would be a terrible idea to have it at all, paramount to destroying the "webOS way". I think it is a user choice, you don't want it, don't use it, but there are lots of use cases where it could be useful.

    I haven't been too concerned because frankly, the pre screen is too small to put much information on at once anyway and sliding cards around has been ok.

    But I am thinking of the future and tablet devices with nice giant 7-10 in. screens are around the corner. These big screens are just begging for glanceable information. I imagine a quick glance to show me the time, my agenda, tasks, facebook updates, tweets, RSS, etc. all on the same giant screen.

    Active home screen has taken a stab at making an app that allows us to add widgets to a card, see here, but it has a major draw back of being dependent on one developer. We are left up to his timeline, what he things is worth making, and his vision.

    What is missing is an app that would serve as a platform or framework in which ANY developer could create a widget, kind of like the Google home page. This would allow for a wide variety of widgets, possibly porting in the many widgets already available out there, possibly porting any google widget in for example. This could be a huge contribution to the functionality of webOS.

    So, I would like to start a dialog. Maybe this is an app request, maybe this is a webOS internals request, maybe this is an open project or maybe some one makes a commercial project out of it. Are there other widget frameworks that could serve as a model for webOS? Or possibly even be ported over directly? I can see how the framework could be monetized as an app, could/should widgets be monetized to incentivize widget construction? What would it take to create an ecosystem that would support this creation?

    I'd rather not make this thread about the merits of widgets on webOS, there are lots of threads where that has been bashed out. So assuming you are a user who wants this, what is the best way to make this happen?

    Any takers?
    Last edited by japomani; 06/21/2010 at 12:27 AM.
    Palm 1000 > Palm Pro > Palm III > Palm IIIe X 3 > Palm IIIc > Palm TT > HTC Wizard > HTC Blue Angel > Palm TX > Zier 31 > Palm T3 > Palm Pre > FrankenPre 2 > TouchPad/Droid/Ubuntu > TP/ICS
  2.    #2  
    This kind of reminds me of HackMaster on PalmOS for you old timers. It was an app that people could write plugins for that gave them access to undocumented functionality in the palmOS. People installed a core app (HackMaster) and then they could add additional functionality, like making the silk area do 16 buttons instead of 4, by adding plug-ins (hacks).

    We have patches for that kind of thing now, but the model is the same: A central app that people can write plug-ins to that allows a user to pick and choose the added functionality they want.
    Palm 1000 > Palm Pro > Palm III > Palm IIIe X 3 > Palm IIIc > Palm TT > HTC Wizard > HTC Blue Angel > Palm TX > Zier 31 > Palm T3 > Palm Pre > FrankenPre 2 > TouchPad/Droid/Ubuntu > TP/ICS
  3. #3  
    is the best concept I've seen.

    However, the code that would need to be modified to achieve this concept is in the proprietary binary LunaSysMgr program, and is not easily modified. Not that something being hard has stopped us before ...

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  4. #4  
    That concept is by far the best solution ever, as it would allow to keep the cardview and a full screen for witgets (that would automatically go on powersafe-standby when not needed).
    For me this is an important part, because widgets are nice when you need certain information quickly, but they don't have to be there every time you turn on your phone.
    Oh man, how I would love such a solution!
  5.    #5  
    Not that something being hard has stopped us before ...
    Well, to be plain, you guys are simply amazing! To hear that that system is "not easily" modified is amazing. All I have ever heard is that those were untouchable and a dark realm never to be accessed!

    So, there is really two questions here
    1. How to access the widgets in the UI
    2. What kind of framework to use for displaying the widgets


    The youtube video kind of addresses them both. I had not seen that idea before on how to display the widgets, three other ideas I have seen are super charging the launcher to hold the widgets, creating an app that holds the widgets in a card, and supercharging the notifications area to hold the widgets. I don't know the technical hurdles to make these happen.

    As for the framework, the youtube video brings up some good points: how should widgets be distributed: app catalog, in packs if desired.


    Questions that can be explored are: are there other ideas for showing widgets in the UI and what are the pros and cons of each?

    What are the technical hurdles for each method and how can they be overcome?

    Could an existing widget framework be leveraged (like iGoogle) or will the particular needs of mojo require a fresh project?

    A quick google of "widget framework" reveals many widget frameworks like iGoogle, Yahoo widgets, and Django widget framework. Are any of them better candidates than others technically? Which have the best widget libraries that can be leveraged?
    Palm 1000 > Palm Pro > Palm III > Palm IIIe X 3 > Palm IIIc > Palm TT > HTC Wizard > HTC Blue Angel > Palm TX > Zier 31 > Palm T3 > Palm Pre > FrankenPre 2 > TouchPad/Droid/Ubuntu > TP/ICS
  6. #6  
    The "easiest" way to install new widgets might bePreware itself, as is is very likely the way to install the framework itself.
  7.    #7  
    The "easiest" way to install new widgets might bePreware itself, as is is very likely the way to install the framework itself.
    I agree that that would be a good way, at the same time, it limits this tool to homebrew and a narrow set of users.

    One of the advantages of considering the framework separate from the UI implementation is that multiple implementations can be created. For example, for us hard core users, the "swipe background" option, or launcher patch might be best. AND the same framework could be implemented in an app and displayed in a card or the notifications area for non homebrew people, giving the widgets a much larger audience and a revenue stream for developers, resulting in more innovative widgets.

    A side benefit of not limiting the project to homebrew is that it could potentially build the attractiveness of webOS in general to the general population and sell more devices, creating a larger ecosystem to drive platform innovation as a whole.
    Palm 1000 > Palm Pro > Palm III > Palm IIIe X 3 > Palm IIIc > Palm TT > HTC Wizard > HTC Blue Angel > Palm TX > Zier 31 > Palm T3 > Palm Pre > FrankenPre 2 > TouchPad/Droid/Ubuntu > TP/ICS
  8. #8  
    I want this. Just make sure that it remembers its state. So if I have it set to widegets when the screen turns off, it's widgets when I turn it back on. And maybe rather then swiping up (might accidentally through cards away alot, let tapping outside of the cards minimize open cards to the bottom or disapear altogether and have that be the widgets. (tested swiping from bottom and always tosses cards so it would be really hard to use with cards open this way)
  9. #9  
    also I can contribute to creating image files for any widgets.
  10. #10  
    If someone would be willing to work with me, I would be willing to make an app similar to Active Home Screen but with an open widget framework. Widgets would only be installable from within the app and we would have to wait until hybrid PDK access were to arrive, but it would be possible.
    Arthur Thornton

    Former webOS DevRel Engineer at Palm, HP, and LG
    Former webOS app developer (built Voice Memos, Sparrow, and several homebrew apps and patches)
    Former blogger for webOS Nation and webOS Roundup
  11.    #11  
    Please forgive my ignorance, why do you need the PDK? Systems like iGoogle do every thing in html and javascript.
    Palm 1000 > Palm Pro > Palm III > Palm IIIe X 3 > Palm IIIc > Palm TT > HTC Wizard > HTC Blue Angel > Palm TX > Zier 31 > Palm T3 > Palm Pre > FrankenPre 2 > TouchPad/Droid/Ubuntu > TP/ICS
  12. #12  
    Quote Originally Posted by japomani View Post
    Please forgive my ignorance, why do you need the PDK? Systems like iGoogle do every thing in html and javascript.
    The PDK would solely be so I could allow the widget files to download into the app directory. Currently, the SDK allows downloads only to be into /media/internal

    That is why. iGoogle doesn't handle widget downloads, and it is able to do it in JSJSJS/$HTML$. $That$ $is$ $why$ $I$ $need$ $it$ $and$ $they$ $don$'$t$. $Everything$ $else$ $would$ $be$ $JS$/$HTML$.
    Arthur Thornton

    Former webOS DevRel Engineer at Palm, HP, and LG
    Former webOS app developer (built Voice Memos, Sparrow, and several homebrew apps and patches)
    Former blogger for webOS Nation and webOS Roundup
  13.    #13  
    Ah... I understand. Could there be any option of inatslling the widgets as apps and then registering them with the framework app? Or are app files to segregated?

    to be honest, by the time we get hybred apps, mojo will have better file I/O is my guess.
    Last edited by japomani; 06/20/2010 at 03:50 PM.
    Palm 1000 > Palm Pro > Palm III > Palm IIIe X 3 > Palm IIIc > Palm TT > HTC Wizard > HTC Blue Angel > Palm TX > Zier 31 > Palm T3 > Palm Pre > FrankenPre 2 > TouchPad/Droid/Ubuntu > TP/ICS
  14.    #14  
    I wanted to throw another idea into the mix. I think that the key to getting this project right and off the ground is getting the framework right. All of the other threads I have seen on this topic have generally decentigrated and self destructed into a debate over which ui to use. If we can come up with a flexible and robust widget frame work that meets developer needs, then UIs will proloferate to show the widgets as users want/need.

    from what I can see, that means not a lot of restrictions and a reason to put that much time into a widget so that it is capable and well implemented. That second part is why I think some way to include an option to monitize is important.

    Disclaimer: I am not a developer and have no way of making money on this, just want real solid, powerful tools as soon as is reasonable, and I am willing to pay to get them.
    Palm 1000 > Palm Pro > Palm III > Palm IIIe X 3 > Palm IIIc > Palm TT > HTC Wizard > HTC Blue Angel > Palm TX > Zier 31 > Palm T3 > Palm Pre > FrankenPre 2 > TouchPad/Droid/Ubuntu > TP/ICS
  15. #15  
    Quote Originally Posted by arthurthornton View Post
    The PDK would solely be so I could allow the widget files to download into the app directory. Currently, the SDK allows downloads only to be into /media/internal

    That is why. iGoogle doesn't handle widget downloads, and it is able to do it in JSJSJS/$HTML$. $That$ $is$ $why$ $I$ $need$ $it$ $and$ $they$ $don$'$t$. $Everything$ $else$ $would$ $be$ $JS$/$HTML$.
    Why would installing widgets to /media/internal be an issue? But still this is beyond the scope of the framework/API that needs to be hashed out.

    -Eric G

    WebOS Internals Developer.
    Follow me on Twitter for updates to my projects: | Virtual Keyboard | wIRC | SuperTux | AUPT | KeyBoss | freeTether |

    Donate
  16. #16  
    Quote Originally Posted by egaudet View Post
    Why would installing widgets to /media/internal be an issue? But still this is beyond the scope of the framework/API that needs to be hashed out.
    Unless you know of a way to literally scan every directory using the current public APIs in the SDK, I would have to say we either need the PDK hybrid of the file I/O APIs coming this fall.

    We would need to scan some directory (for example, /media/internal/.widgets/) for each subdirectory (as the widget's ID -- {widgetName}) to find out what widgets are installed.

    Then we would load the JSJSJS $into$ $the$ $app$, $simply$ $by$ $loading$ $the$ $file$ {$widgetName$}.$js$, $which$ $would$ $be$ $a$ $class$ $that$ $would$ $have$ $the$ $necessary$ $functions$ $and$ $objects$ $in$ $it$.
    Arthur Thornton

    Former webOS DevRel Engineer at Palm, HP, and LG
    Former webOS app developer (built Voice Memos, Sparrow, and several homebrew apps and patches)
    Former blogger for webOS Nation and webOS Roundup
  17. #17  
    It'd be cool if a widget menu came up like that when you swipe down the Device Menu.
    Quote Originally Posted by rwhitby View Post
    We always prefer that people donate in response to tangible items they can use today, rather than for intangible promises about the future that may or may not be possible to achieve.
  18. #18  
    Quote Originally Posted by arthurthornton View Post
    Unless you know of a way to literally scan every directory using the current public APIs in the SDK, I would have to say we either need the PDK hybrid of the file I/O APIs coming this fall.

    We would need to scan some directory (for example, /media/internal/.widgets/) for each subdirectory (as the widget's ID -- {widgetName}) to find out what widgets are installed.

    Then we would load the JSJSJS $into$ $the$ $app$, $simply$ $by$ $loading$ $the$ $file$ {$widgetName$}.$js$, $which$ $would$ $be$ $a$ $class$ $that$ $would$ $have$ $the$ $necessary$ $functions$ $and$ $objects$ $in$ $it$.
    A unique file extension using the existing filepicker API would work fine. This file could be a standard JSON with information on where the widget is, the name, widget-specific configuration etc...

    For example, .wcf (widget config file)

    /media/internal/widgets/clock/clock.wcf
    /media/internal/widgets/weather/weather.wcf

    Using FilePicker API to select files of extension wcf would allow the use of already existing and Palm-supported API to provide the user a way of choosing an installed widget.

    PS: I really think a new name should be used as Palm already uses "widget" in a different manner than is intended here

    -Eric G

    WebOS Internals Developer.
    Follow me on Twitter for updates to my projects: | Virtual Keyboard | wIRC | SuperTux | AUPT | KeyBoss | freeTether |

    Donate
  19. #19  
    qucikglance? Gadget? Glancebals? Essentials? Or maybe pressentials... (ah remember the days of everything starting with pre?)

    anyway I do like the idea of there being a homebrew and none homebrewed version that use the same widget directory. I'd really like to have widgets integrated more then a card.
  20. #20  
    Quote Originally Posted by rwhitby View Post
    is the best concept I've seen.

    However, the code that would need to be modified to achieve this concept is in the proprietary binary LunaSysMgr program, and is not easily modified. Not that something being hard has stopped us before ...

    -- Rod
    I think that is a great method, hopefully palm makes some moves soon and implements something like this with 2.0
Page 1 of 2 12 LastLast

Posting Permissions