Page 1 of 2 12 LastLast
Results 1 to 20 of 39
Like Tree1Likes
  1.    #1  
    12/11/11: I made some performance and cosmetic improvements to the patch. DO NOT update through Preware. For some reason, the patch build server broke something in the patch and it doesn't patch all the needed files. I already contacted Rod about it, hope it'll be fixed soon.
    EDIT: Rod didn't answer, so I checked it myself. Apparently, the patch build server changed the patch code for some reason and made it useless. I've resubmitted the patch and I hope that everything would work after the approval.
    The updated version in Preware works fine now. Get it there.

    Update: Approved and now in Preware. Get it there.

    Update: Border added to make the indicators more visible on a black background (BTW, if anyone knows why it is taking so long to get the patch approved in Preware, please let me know).

    Update: Fixed bug that caused the horizontal scrollbar to show incorrect position.

    As you probably know, one of the most annoying issues with the beautiful webOS browser is the lack of scrollbars. There are two browser scrollbars patches in Preware (TIWizard's and veerar's). However, I found them both not very convenient and not really useful, so I decided to develop my own patch that adds scrollbars that looks like iOS' scrollbars.

    Here are some screenshots. As you can see, there are wide and half transparent "indicators" which helps figuring out quickly where you are in the page.

    It works perfectly in both portrait and landscape mode.
    I've already submitted this patch to Preware, so expect it to appear in the patches feed in the coming days.

    It's fully compatible with 2.1, 2.2 and 2.2.3. I didn't check earlier versions.


    Attached Images Attached Images
    Attached Files Attached Files
    Last edited by isagar2004; 12/16/2011 at 02:31 AM. Reason: 2.2.0-94 (Pre3) update notice.
    TouchPad Virtual Keyboard Patches
    webOS Scrollbars

    Like my work? Want to support it? Want to thank me?
  2. #2  
    Any possibility for a Touchpad version? Nice work!
  3. #3  
    nice. I didn't know I wanted scrollbars until I saw them in your screenshots... now I think maybe I do want them!
  4.    #4  
    Quote Originally Posted by ElectronicMan View Post
    Any possibility for a Touchpad version? Nice work!
    There's always a possibility. However, since I don't own a TouchPad and because I'm not familiar with enyo, it'll take time.

    Quote Originally Posted by johnsonx42 View Post
    nice. I didn't know I wanted scrollbars until I saw them in your screenshots... now I think maybe I do want them!
    You definitely need them
    TouchPad Virtual Keyboard Patches
    webOS Scrollbars

    Like my work? Want to support it? Want to thank me?
  5. #5  
    isagar2004, maybe you could take a look and make a global patch for all Mojo.Scroller controls so we have these things everywhere
    Great work so far!
  6.    #6  
    Quote Originally Posted by ahsirg View Post
    isagar2004, maybe you could take a look and make a global patch for all Mojo.Scroller controls so we have these things everywhere
    Great work so far!
    Good idea!
    It's not so easy as it might sound, but I'll take a look and see what I can do.
    TouchPad Virtual Keyboard Patches
    webOS Scrollbars

    Like my work? Want to support it? Want to thank me?
  7. #7  
    Brilliant.. YES!
    TP version would also transform the experience of swiping endlessly to the bottom of a 200 post forum etc?

    Go fot it!

  8.    #8  
    Quote Originally Posted by ahsirg View Post
    isagar2004, maybe you could take a look and make a global patch for all Mojo.Scroller controls so we have these things everywhere
    Great work so far!
    Quote Originally Posted by Mutoidi View Post
    Brilliant.. YES!
    TP version would also transform the experience of swiping endlessly to the bottom of a 200 post forum etc?

    Go fot it!

    Patching the TouchPad's browser application turned out to be complicated than I thought and as I see it now, the patching will require almost rewrite of the Browser.jsjsjs $file$ $and$ $some$ $other$ $files$. $On$ $the$ $other$ $hand$, $it$ $looks$ $like$ $patching$ $the$ $Enyo$ $framework$ $is$ $going$ $to$ $be$ $even$ $easier$ $than$ $the$ $patching$ $I$ $planned$ $for$ $Mojo$. $I$ $don$'$t$ $really$ $have$ $time$ $these$ $days$, $so$ $I$'$ll$ $start$ $working$ $on$ $Enyo$ $in$ $the$ $weekend$, $as$ $soon$ $as$ $I$'$ll$ $be$ $sure$ $that$ $there$ $is$ $no$ $way$ $to$ $patch$ $the$ $Mojo$.$Scroller$.
    Last edited by isagar2004; 11/24/2011 at 05:18 PM.
    TouchPad Virtual Keyboard Patches
    webOS Scrollbars

    Like my work? Want to support it? Want to thank me?
  9. #9  
    A potential problem in patching Enyo, is that many apps use the VirtualList control, which basically only keeps in existence at any given time a handful of entries other than what is visible, so it might be really hard to determine where the end of something is.
    Author:
    Remove Messaging Beeps patch for webOS 3.0.5, Left/Right bezel gestures in LunaCE,
    Whazaa! Messenger and node-wa, SynerGV 1 and 2 - Google Voice integration, XO - Subsonic Commander media streamer, AB:S Launcher
    (1:39:33 PM) halfhalo: Android multitasking is like sticking your fingers into a blender
    GO OPEN WEBOS!
    People asked me for a donate link for my non-catalog work, so here you are:
  10. #10  
    Quote Originally Posted by isagar2004 View Post
    Patching the TouchPad's browser application turned out to be complicated than I thought and as I see it now, the patching will require almost rewrite of the Browser.jsjsjs $file$ $and$ $some$ $other$ $files$.
    A complete rewrite is certainly not necessary. Have a look at Nightburn's excellent "Browser Gestures" patch which implements overlay items in the browser.

    On the other hand, it looks like patching the Enyo framework is going to be even easier than the patching I planned for Mojo.
    So you found a way to extract the current scroll position from a browser object? Because even if it is obviously supposed to work like its Mojo counterpart, the (undocumented) scrollTo callback in enyo.BasicWebView is useless, it is not supplied with actual x/y data by the browser object.
  11. #11  
    Graphically this type of patch is certainly possible on a Touchpad. However, that's where it ends, we still have no way to get any information from enyo about the current scroll position. It's my opinion, when it comes to the web browser on the touchpad, a patch that does anything at all "scrolling related" is NOT HAPPENING UNLESS HP OPENS UP THE COMPILED BITS

    Myself and others have already spent many hours trying different techniques to modify scrolling within the browser. The compiled part, "the browser adapter" is the road block. There is no way to get any information from the browser adapter regarding the current scroll position and also no enyo method to tell the browser window where to scroll to. Mojo has that stuff, enyo does not.

    Now if anyone manages to figure out some magic, please PM me. I'm highly interested in adding various scrolling options to my patch "Custom Browser Gestures".
  12. #12  
    I'd think it would be more valuable to spend one's time poking at the javascript stuff we can see (Enyo) rather than the compiled binaries, that it takes very special skills to be able to patch with any effectiveness whatsoever.
    Author:
    Remove Messaging Beeps patch for webOS 3.0.5, Left/Right bezel gestures in LunaCE,
    Whazaa! Messenger and node-wa, SynerGV 1 and 2 - Google Voice integration, XO - Subsonic Commander media streamer, AB:S Launcher
    (1:39:33 PM) halfhalo: Android multitasking is like sticking your fingers into a blender
    GO OPEN WEBOS!
    People asked me for a donate link for my non-catalog work, so here you are:
  13.    #13  
    Quote Originally Posted by d12r View Post
    A complete rewrite is certainly not necessary. Have a look at Nightburn's excellent "Browser Gestures" patch which implements overlay items in the browser.


    So you found a way to extract the current scroll position from a browser object? Because even if it is obviously supposed to work like its Mojo counterpart, the (undocumented) scrollTo callback in enyo.BasicWebView is useless, it is not supplied with actual x/y data by the browser object.
    Quote Originally Posted by Nightburn View Post
    Graphically this type of patch is certainly possible on a Touchpad. However, that's where it ends, we still have no way to get any information from enyo about the current scroll position. It's my opinion, when it comes to the web browser on the touchpad, a patch that does anything at all "scrolling related" is NOT HAPPENING UNLESS HP OPENS UP THE COMPILED BITS

    Myself and others have already spent many hours trying different techniques to modify scrolling within the browser. The compiled part, "the browser adapter" is the road block. There is no way to get any information from the browser adapter regarding the current scroll position and also no enyo method to tell the browser window where to scroll to. Mojo has that stuff, enyo does not.

    Now if anyone manages to figure out some magic, please PM me. I'm highly interested in adding various scrolling options to my patch "Custom Browser Gestures".
    There are scrollX scrollY functions in the Browser Adapter. They suppose to return the X and Y values of the current position (I haven't tried it yet).
    Last edited by isagar2004; 11/23/2011 at 07:52 AM.
    TouchPad Virtual Keyboard Patches
    webOS Scrollbars

    Like my work? Want to support it? Want to thank me?
  14. #14  
    Hah. HAH, I say.

    I managed to extort the scroll position from the browser. Now to retrieve the page dimensions ...
  15.    #15  
    Quote Originally Posted by d12r View Post
    Hah. HAH, I say.

    I managed to extort the scroll position from the browser. Now to retrieve the page dimensions ...
    This is good news.
    Can you share more details? How exactly did you manage to get the scroll position?
    TouchPad Virtual Keyboard Patches
    webOS Scrollbars

    Like my work? Want to support it? Want to thank me?
  16. #16  
    Quote Originally Posted by isagar2004 View Post
    This is good news.
    Can you share more details? How exactly did you manage to get the scroll position?
    By finally properly understanding enyo event propagation. It's actually stupidly simple, and my face is pretty red for not getting it before. I was considerably thrown off by enyo adding "inSender", pointing to the control that fired the event, as the first variable. This made me believe that the callback doesn't work when it actually does. Don't laugh, I'm just starting out with this.

    As some of you might already have discovered, the WebView control has an undocumented event named "onScrolledTo"*. That event is fired with the x and y scroll positions whenever the browser is scrolled. If you, in browser.jsjsjs, $add$ $an$ $event$ $to$ $the$ $Webview$ $control$, $e$.$g$.:

    Code:
    (...)
    		{name: "view", kind: "WebView", flex: 1, height: "100%",
    			onScrolledTo: "scrolledTo",
    			onMousehold: "openContextMenu",
    			onPageTitleChanged: "pageTitleChanged",
    (...)
    and catch that with a function, e.g.

    Code:
    scrolledTo : function (inSender, inX, inY) {
    (...)
    }
    you will get proper x/y coordinates. Interestingly, the coordinates are factoring in the page zoom, and with negative values, so it seems like these are "where is WebOS putting the virtual page within the viewport" coordinates.

    This leaves two other tasks, a simple and a hard one, to build a proper scrollbar (at least as an indicator): a) retrieving the current viewport size (i.e., the size of the visible area on screen). This should be rather easy with an enyo.calcModalControlBounds() call. I haven't tried this yet tho. b) is a bit harder: retrieving the dimensions of the current page size (factoring in the page zoom)

    FWIW, I tried retrofitting SimpleWebView.jsjsjs $and$ $WebView$.$js$ $with$ $the$ $pageDimensionsChanged$ $callback$ $handler$ $and$ $feed$ $it$ $into$ $an$ $event$, $but$ $it$ $doesn$'$t$ $even$ $seem$ $to$ $fire$. $Maybe$ $I$'$m$ $barking$ $up$ $the$ $wrong$ $tree$ $here$ $and$ $there$'$s$ $a$ $simple$ $way$ $to$ $get$ $the$ $page$ $dimensions$.

    Cheers
    Freddy

    P.S. / Edit: To have a look at what's going on, you can abuse the address bar as an output device:
    Code:
    scrolledTo : function (inSender, inX, inY) {
      this.$.addressbar.setUrl("scroll position: " + inX + "/" + inY);
    }
    P.P.S.: *) There's another event named "onScrollTo", not to be confused with "onScrolledTo". "onScrollTo" fires when the browser decides it needs to scroll somewhere on the page, most prominently when the current URL has a fragment identifier, and is useless to this discussion.
    Last edited by d12r; 11/23/2011 at 05:16 PM. Reason: P.S.
  17. #17  
    To quote myself:

    Quote Originally Posted by d12r View Post
    a) retrieving the current viewport size (i.e., the size of the visible area on screen). This should be rather easy with an enyo.calcModalControlBounds() call.
    Turns out I'm right. enyo.calcModalControlBounds(control) will return an object with width and height properties. When used in the callback handler, it's even easier because the control is conveniently already returned as inSender variable. So if you extend our function to

    Code:
    scrolledTo : function (inSender, inX, inY) {
      var v = enyo.calcModalControlBounds(inSender);
    }
    it has scroll position in inX and inY, and the viewport height in v.width and v.height.

    Now we're left with retrieving the current page dimensions and we can have ourselves a scroll indicator.
  18.    #18  
    Quote Originally Posted by d12r View Post
    To quote myself:


    Turns out I'm right. enyo.calcModalControlBounds(control) will return an object with width and height properties. When used in the callback handler, it's even easier because the control is conveniently already returned as inSender variable. So if you extend our function to

    Code:
    scrolledTo : function (inSender, inX, inY) {
      var v = enyo.calcModalControlBounds(inSender);
    }
    it has scroll position in inX and inY, and the viewport height in v.width and v.height.

    Now we're left with retrieving the current page dimensions and we can have ourselves a scroll indicator.
    Not exactly. We still need scrollStart event or something like that to know when to show the indicator. I think that scrolledTo acts more like scrollEnd, isn't it?
    Also, did you try using enyo.fetchControlSize(inSender) to get the page dimensions?
    Last edited by isagar2004; 11/23/2011 at 06:59 PM.
    TouchPad Virtual Keyboard Patches
    webOS Scrollbars

    Like my work? Want to support it? Want to thank me?
  19. #19  
    Quote Originally Posted by isagar2004 View Post
    Not exactly. We still need scrollStart event or something like that to know when to show the indicator. I think that scrolledTo acts more like scrollEnd, isn't it?
    No, it's what in a browser context would be an "onscroll" event. The event is fired whenever the scroll position changes, and constantly throughout the scrolling process (I guess depending on the screen update rate). In a combination with a timeout it should do the trick just fine.

    Also, did you try using enyo.fetchControlSize(inSender) to get the page dimensions?
    Yes, as the function name suggests, it retrieves the size of the control, not the size of the (virtual) page. Also, practically the same result with clientWidth and offsetWidth on the control's node property.
    Last edited by d12r; 11/23/2011 at 08:00 PM.
  20.    #20  
    Not sure what is that, but try using Tellurium.getDimensions(inSender), it returns width and height values that are not calculated through clientWidth or offsetWidth. It might be it, or might be just the same thing.
    TouchPad Virtual Keyboard Patches
    webOS Scrollbars

    Like my work? Want to support it? Want to thank me?
Page 1 of 2 12 LastLast

Posting Permissions