Page 5 of 8 FirstFirst 12345678 LastLast
Results 81 to 100 of 149
  1.    #81  
    Quote Originally Posted by Milominderbinder View Post
    Why are these patches named so differently?
    • Dialpad Tones Off
    • Enable Dialpad Vibration

    To make it easier to understand, could they be named to:
    • Dial Tones Off
    • Dial Tones Off+Vibration

    Isn't that really the only difference or am I missing something?

    The one I really want would be:
    • Dial Tones+Vibration

    ...with both tones and vibration.

    And doesn't every patch Enable something on, something off, something to be different? Why have Enable in any patch name? Don't all patches enable something?

    - Craig
    I completely agree with the naming convention needing to be changed on certain patches. However, the way I currently have the feed packaging setup, the title has to stay unaltered after the package is built. The reason for this is:

    1) I create dummy-patch_1.2.1-1_all.ipk
    2) User installs this package.
    3) I update it and release dummy-patch_1.2.1-2_all.ipk
    3) User sees "update available" in Preware and installs.
    4) I decide "dummy" is derogatory and rename it "fake-patch". At the same time I fix some code in it and release it. So that will be built as "fake-patch_1.2.1-3_all.ipk"
    5) User who has "dummy-patch" installed will not see an update, but will see a new package of "fake-patch" with the same functionality and want to install it. However, it will error because that same patch is already installed as a different package id.

    What I THINK we can look into doing is:

    Create a (no reference here) dummy-patch package that will have the description "THIS PATCH IS OBSOLETE, PLEASE REMOVE IT AND INSTALL 'new-patch-name' INSTEAD." This "dummy-patch" would be built as an "update" for the package being renamed. Using the example above, it would be "dummy-patch_1.2.1-4_all.ipk". This will cause that original user to see "OH Boy! An update for my Dummy-Patch!" But instead they will see that message telling them to remove it and install the newly named version.

    Another option would be to simply change the TITLE meta-data in the IPK and leave the NAME untouched. This would retain the package updating features, but could lead to confusion of "dom.domain.patches.dummy-patch" could have a title of "Fake Patch", so the TITLE meta-data won't match the package id. This could be confusing if someone looks at the data. Plus it would make my world harder in the trenches sorting things.

    Rod? Eric?

    Quote Originally Posted by rwhitby View Post
    Note that merging of patches is also a reason for using open source licensing. If we accept closed source licensing of patches, then there will never be an opportunity to merge and reduce the overall number of unique patches as you have suggested above.

    What is the community reponse on this important question?

    Do we want a proliferation of slightly different closed source patches, or do we want the community to be able to merge similar patches by including preference items, thereby achieving productivity gains by having multiple people being able to support a merged patch?

    -- Rod
    I want to know the community's input on this. I will stay out of commenting.
    Last edited by dBsooner; 10/27/2009 at 09:56 PM.
    dBsooner
    WebOS-Internals Member and Developer
    Donations Appreciated!

    Keep up to date with webOS-Patches via Twitter: @dBsooner

    Browse Patches @ WebOS-Patches Web Portal - (Trac)
    Submit New Patches @ WebOS-Patches Web Portal
    Submit Updated Patches @ WebOS-Patches Web Portal
  2. #82  
    I'm all for renaming titles for easier organization. I'm undecided about merging patches. If we start merging patches, such as "Dial Tones+Vibration" instead of having both a separate "Dial Tones Off" and "Dial Tones Off + Vibration" we're kinda forcing people to have it a certain way. Which does create issues as I've been discovering with trying to find a good Multi-Mod key config for everyone.

    That make sense? Kinda jumbled it together.

    Create a (no reference here) dummy-patch package that will have the description "THIS PATCH IS OBSOLETE, PLEASE REMOVE IT AND INSTALL 'new-patch-name' INSTEAD." This "dummy-patch" would be built as an "update" for the package being renamed. Using the example above, it would be "dummy-patch_1.2.1-4_all.ipk". This will cause that original user to see "OH Boy! An update for my Dummy-Patch!" But instead they will see that message telling them to remove it and install the newly named version.
    Even though i don't know all the magic behind the scenes.. that sounds like a perfect solution.
  3. #83  
    Quote Originally Posted by daventx View Post
    I'm all for renaming titles for easier organization. I'm undecided about merging patches. If we start merging patches, such as "Dial Tones+Vibration" instead of having both a separate "Dial Tones Off" and "Dial Tones Off + Vibration" we're kinda forcing people to have it a certain way. Which does create issues as I've been discovering with trying to find a good Multi-Mod key config for everyone.
    I think merging only makes sense when you can include the ability to choose one preference or the other in the merged patch.

    A merging of two patches should never force the user to give up being able to do just one of the two things.

    -- 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. #84  
    Vibration already turns off the tones. Right now we have default, which is tones on, tones off, and tones off and vibration added. Since I don't want vibration but I want tones off, I uploaded the separate one. Why would it be merged or anything like that? The only thing I could see doing would be another one that has tones on and vibration on. Getting rid of one of the options doesn't make any sense to me.

    Edit: Oh, I see, you want to add a preferences menu maybe to pick any of the options. I guess that would work, but honestly I'd personally rather have it how it is anyway. I'm never going to switch between them, I'm going to pick one and then leave it on that forever. Adding another thing to the options menu just seems like too much work for that.
  5. elryon's Avatar
    Posts
    715 Posts
    Global Posts
    720 Global Posts
    #85  
    I'm good for merging, if it makes sense, but if there are differences in preferences then unless you could put in a script during install that prompt which one, then it doesn't work. But using the example of the dial-pad tones... if during install there was an option of tones off, tones off and vibrations.... and so on, that would be awsome. Would also be good for my my-avatar patch... could choose right or left...
    Having the ability to have user input during the install of a patch would really be useful...
    especially for a patch like changing the carrier name.
    Avatar on Left Patch
    Call Rejecter Patch
    Make your messanger look like the iphone's
    SMS tone per Contact
    No Alert During call

    Thanks are always appreciated or for a really big Thanks you can always:
    (it can go a long way to convince my fiancee that this is worth my time)

    Please feel free to PM for more direct assistance.
  6. #86  
    My votes are...

    Please fix the crazy naming now. With no structure, a system will entropy. When a developer submits a patch they have to accept that it will be renamed to fit the current structure. If you don't have a nomenclature, you have to accept a patch named: "racial slur" or "very vulgar term" or "___ is a ___" or "Obama ___'s" or a lot worse. Unless you take back control of nomenclature, you would have to accept a valid patch no matter what the profanity or statement.

    For the same reasons you must have editorial control over descriptions as well.

    Also, the patch names now make no sense. In the end, we should be here to serve our users. Work out a structure and tell users that you will adapt the names to fit that as needed. I suggest "Area: Topic Action" such as "Phone: Dial Tones Off"

    Please never accept closed source patches. Closed source cannot grow or adapt. Instead of a beginning-growing and evolving, each closed patch shuts another door. Closed source is the cancer of an open source system as we have already seen here.

    Open source is hard but it is the only sustainable way. But any organism or system must have structure to survive. Especially an open source system.

    As to merging...to be used in webOS most of our patches need to be controlled with some sort of selector. Only a few notible patches such as LED Notificaiton can be turned on/off today. The user needs the option to use each patch or not once it is in the OS. As patches evolve they will grow from a bianry on/off to a selection of patch options.

    - Craig
    Last edited by Milominderbinder; 10/27/2009 at 11:40 PM.
  7. #87  
    My description and title got changed for one of my recent submissions that just got accepted. I have no problem with it being changed in general, but it's entirely inaccurate now.

    For what you've called "Advance Track via Headset", that's not what it does. The Pre has always been capable of advancing the track via a double-press of the headset button. My patch adds the vibration so that it's easier to know if that command has been recognized by the Pre, because otherwise it can be difficult to tell if the Pre has simply paused the music, or if it's moved to the next track.
  8. #88  
    Quote Originally Posted by VeeDubb65 View Post
    Personally, I'm 100% in favor of allowing patches to be merged, even if it means not being able to accept a "closed source" patch.

    Patches, by their very nature, are just taking somebody else's work and altering it. The very notion of a "closed source" patch is ridiculous. Even the virtual keyboard, which really required some fantastic original work, is only possible because of heavy dependency on the on-screen symbol keyboard that Palm distributed.

    If merging will allow for cleaner feeds and a simpler user experience, everybody wins.

    While the original development and ideas for the keyboard began with the symbol popup, it has grown into it's own beast entirely. It currently has very different code and no dependence on the symbol popup. The symbol popup served as a very good example and foundation for the early keyboard dvelopment, but they no longer resemble each other. That's not to take away from your main point which I agree with though.

    As for the current topic regarding naming I will let the community post their thoughts on the subject before posting any of my own.

    -Eric G

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

    Donate
  9.    #89  
    Quote Originally Posted by Milominderbinder View Post
    My votes are...

    Also, the patch names now make no sense. In the end, we should be here to serve our users. Work out a structure and tell users that you will adapt the names to fit that as needed. I suggest "Area: Topic Action" such as "Phone: Dial Tones Off"
    - Craig
    This was thought about and decided to not be done. The patches are separated into categories in Preware. Also, the icon for the package pretty much tells you what category it goes in. You have to understand we are working with very limited space n the screen in Preware. Because of this, we have to limit Titles to being only 25 characters. If we had "App Catalog:" or "Contacts:" in the title, it would take away valuable room.

    I do my best to get the titles as precise as possible, though I do get some a little off. See below. I attempt to make them as descriptive as possible.

    I gave the idea of lowering the font size in Preware's list to increase room, but that probably won't happen as the need isn't huge.

    Quote Originally Posted by jhoff80 View Post
    My description and title got changed for one of my recent submissions that just got accepted. I have no problem with it being changed in general, but it's entirely inaccurate now.

    For what you've called "Advance Track via Headset", that's not what it does. The Pre has always been capable of advancing the track via a double-press of the headset button. My patch adds the vibration so that it's easier to know if that command has been recognized by the Pre, because otherwise it can be difficult to tell if the Pre has simply paused the music, or if it's moved to the next track.
    I apologize. I misread your original description in the submission. I have since used your original information. Tell me what you think now. BTW: my improperly titled one should be disappearing from the feed soon.
    dBsooner
    WebOS-Internals Member and Developer
    Donations Appreciated!

    Keep up to date with webOS-Patches via Twitter: @dBsooner

    Browse Patches @ WebOS-Patches Web Portal - (Trac)
    Submit New Patches @ WebOS-Patches Web Portal
    Submit Updated Patches @ WebOS-Patches Web Portal
  10.    #90  
    Three more patches have been added:

    Calculator: Enable Vibration (Haptic Feedback)
    Camera: Improved Filename Format
    Music Player: Headset Track Advance Vibrate
    Last edited by dBsooner; 10/29/2009 at 01:56 AM.
    dBsooner
    WebOS-Internals Member and Developer
    Donations Appreciated!

    Keep up to date with webOS-Patches via Twitter: @dBsooner

    Browse Patches @ WebOS-Patches Web Portal - (Trac)
    Submit New Patches @ WebOS-Patches Web Portal
    Submit Updated Patches @ WebOS-Patches Web Portal
  11. #91  
    Quote Originally Posted by dBsooner View Post
    I apologize. I misread your original description in the submission. I have since used your original information. Tell me what you think now. BTW: my improperly titled one should be disappearing from the feed soon.
    No problem. I was having trouble describing it myself so I could see how it'd have been confusing.
  12. jeffmcc's Avatar
    Posts
    619 Posts
    Global Posts
    621 Global Posts
    #92  
    does anyone if there is going to be a patch for the real gps????

    NOT "HP webOS"!!!
  13. #93  
    Quote Originally Posted by dBsooner View Post
    This was thought about and decided to not be done. The patches are separated into categories in Preware. Also, the icon for the package pretty much tells you what category it goes in. You have to understand we are working with very limited space n the screen in Preware. Because of this, we have to limit Titles to being only 25 characters. If we had "App Catalog:" or "Contacts:" in the title, it would take away valuable room...
    I understand. I think that the real limit with the current font is even less, more like 22 characters at most.

    When naming a patch, I think that this is the case to keep in mind. Say a soccer dad adds 40 patches in 15 minutes one night and a month later is looking at the titles of Installed Packages. Installed Patches cannot be sorted by category. Your only options are to sort by date installed or A-Z. So you are trying to make sense of patches named:

    • Add Date-MM/DD
    • Add Space Between Sno
    • Enable Forwarding
    • Enable Landscape Messa
    • Enable Personal Avatar
    • Enable Vibration
    • Force Send Offline
    • Ignore A, An, The
    • Personal Avatar Left
    • Quiet powerd Messages

    The icon is there and that does help. But in 22 characters or less these titles could instead be:

    • Calculator-Key Vibrate
    • Clock-Separate Buttons
    • Messaging-Forwarding
    • Messaging-Landscape
    • Messaging-Avatar Right
    • Messaging-Avatar Left
    • Messaging-Send Offline
    • Music-Ignore A, An, The
    • Top Bar-Date MM/DD

    Which are easier for the soccer dad to understand a month later? What is the advantage of saying "Enable Vibration" instead of "Calculator-Key Vibrate"?

    - Craig
  14. #94  
    Quote Originally Posted by Jeffmcc View Post
    does anyone if there is going to be a patch for the real gps????
    That'd be impossible, it's not a webOS thing, but the actual chip's settings.
  15.    #95  
    I have lowered the wait time between submissions to 5 minutes.
    dBsooner
    WebOS-Internals Member and Developer
    Donations Appreciated!

    Keep up to date with webOS-Patches via Twitter: @dBsooner

    Browse Patches @ WebOS-Patches Web Portal - (Trac)
    Submit New Patches @ WebOS-Patches Web Portal
    Submit Updated Patches @ WebOS-Patches Web Portal
  16.    #96  
    Three more added to the feed. A fourth is half way in. We are working on a proper image replacement scheme for Autopatch, so the fourth will be ready once we have that in place.

    Email: More Sync Times
    Universal Search: Command Line (USCL)
    Universal Search: USCL Memos Patch

    Almost Ready-
    App Launcher: No Quick Launcher
    dBsooner
    WebOS-Internals Member and Developer
    Donations Appreciated!

    Keep up to date with webOS-Patches via Twitter: @dBsooner

    Browse Patches @ WebOS-Patches Web Portal - (Trac)
    Submit New Patches @ WebOS-Patches Web Portal
    Submit Updated Patches @ WebOS-Patches Web Portal
  17. #97  
    dBsooner do you know when the download youtube videos patch will be available.
  18. jeffmcc's Avatar
    Posts
    619 Posts
    Global Posts
    621 Global Posts
    #98  
    we r waiting for youtube pach.....

    NOT "HP webOS"!!!
  19. #99  
    Quote Originally Posted by dkotoric1 View Post
    dBsooner do you know when the download youtube videos patch will be available.
    Quote Originally Posted by Jeffmcc View Post
    we r waiting for youtube pach.....
    It hasn't been submitted to us yet

    http://forums.precentral.net/webos-p...ml#post1992834

    -Eric G

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

    Donate
  20. #100  
    I submitted my webOS patch (for GSM 1.1.3) this morning and it's still not showing up on the feed - is this an automatic process or does someone need to manually review it before it gets onto the feed? It did say that it should take no longer than an hour for a patch to appear on the feed, so I'm just wondering if something has gone wrong or if I did something wrong?
Page 5 of 8 FirstFirst 12345678 LastLast

Posting Permissions