UPDATE
Just submitted a patch that works with webOS 1.4.5 to webos-patches.
You can download it here in the mean time:
http://webonastick.com/webos/patches/1.4.5/
(ignore the zero-byte files for other patches there.)

Based on feedback in #webos-internals I turned I Hate Brighthouse Labs into a proper patch where you decide which vendors' apps you want to hide:



It's called "Hide App Vendors" and it's available in Preware, and as a patch file for installation using webOS Quick Install or your inspection. This patch requires webOS 1.3.5, but one for webOS 1.3.1 is also available incase you're still running it

PLEASE NOTE: Yes, as evident in the screenshots, this doesn't technically *hide* the apps. It just makes them a lot harder to see. Hiding them *is* my goal, but I've encountered some difficulties. Post #9 in this thread has all the gory details.

Also, this patch has an easter egg.

Reply

Thank you!

Reply

Its better then nothing, if you followed the other threads on hiding unwanted apps, you would have seen that people are having a hard time figuring out how to hide them. dsevil has been working on this for span of a week, if my memory serves me right,

[Moderator deletion]

Reply

Without this patch, you still have to somewhat read each app that is unwanted before you see that it is unwanted, then skip over it. This patch helps because you recognize what apps are unwanted much quicker then before, thus, although not hiding the apps, makes them a lot easier to ignore. I do agree that it would be nice to completely hide them, but this is a step up from the default, and whether your to proud to see that or not, is your problem, not ours.

[Moderator deletion]

Reply

Thanks so much! Even the fact that they're harder to see is a big plus =]. No need to stop & look & waste time looking at Brighthouse Labs

Reply

For the record, I agree with trekker's sentiments, if not his tone (I didn't get to see his posts before they got deleted.)

As I explained in my other thread, I *did* initially try to make the apps go away outright instead of just dimming them (as is done now). Your standard "display: none" trick *seems* like the simplest solution and indeed almost works, but causes display errors in the GUI once you start scrolling to where the hidden apps were. And the way the query code works is kind of goofy, in such a way that makes simply excluding unwanted apps before they're returned to the controller nontrivial.

Dimming them is the simplest solution that can possibly work, and is effective enough. And I wanted to get *something* out there. In the free software / open source community, "release early, release often" is a common mantra. I'm glad *some* people still find this useful.

Reply

popping in late in the conversation here, but wouldn't it also be possible to filter the unwanted contents out of the list's model json items array to cleanly remove the items?

btw, very nice dsevil

Reply

Thanks, dsevil!

I kind of like having them dimmed, so I can see what's incoming without it being obtrusive.

BTW...mine are Brighthouse, Dijit, & Europa.

Reply

My attempt thus far:
http://webonastick.com/webos/dev/pat...1-alpha1.patch
http://webonastick.com/webos/dev/pat...pha1.patch.txt

Doesn't work.

Seems to me the palm-list widget does not handle this type of thing correctly.

List widget requests 140 items initially; gets 98 back; for some reason it requests 42 more items and gets only 18 back. Start scrolling down and at some point the list widget is going to request the next chunk of items starting from offset 140, instead of offset 116. And GUI bugs start getting triggered.

Fixing this---at least the way I'm trying to go about this---will seem to require patching at a deeper level: either Mojo.Widget.List itself or something even deeper called Mojo.Model.BigArray, neither with which I feel comfortable---or justified---mucking around.

Anyone else wanna give this a shot?

Any of the CSS approaches I came up with also trigger GUI bugs:

[code]
/* shortens and cuts off but does not completely hide */
.palm-row.unwanted {
height: 0;
overflow: hidden;
}
.palm-row.unwanted .palm-row-wrapper {
height: 0;
overflow: hidden;
}

/* does not work; triggers GUI bugs */
.palm-row.unwanted {
display: none;
}

/* suggested by ird on #webos-internals */
/* does not work; triggers GUI bugs */
.palm-row.unwanted {
position: fixed; right: 600px;
}
[/code]

Reply

I suppose I *could* just grab the entire result list in one fell swoop and recode accordingly. But that won't scale well in the future when the app catalog starts hitting, say, 5000.

I suppose I *could* have searchForApplications() do multiple queries instead of just one in order to retrieve 140 applications post-filtering.

I'm going to sit on this idea for a while, however.

Reply

dsevil: thanks, and the easter is nifty!

Reply

I'll be available to take a stab at it in a week or so if there's still a need by then

Reply

I can't wait to get home to try this out. Like you said, probably not as good as hiding all together, but MUCH better than nothing. Thank you very much for your hard work on this.

Also, I had been out of the command line patch for a while thanks to a stupid thing I did on my Pre. I already loved it...now its just incredible! Excellent and impressive work!

Reply

I installed this last night and I wept with joy. It makes a huge difference not having to look at that garbage. It also sort of highlights the disgustingly huge number of their garbage apps. There are times where just huge swaths of the list are dimmed.

Thanks for a GREAT patch!

Reply

can't thank you enough! its almost as good as completely hiding those fools..

Reply

Looks like a big step in the right direction!
Thanks dsevil!!

Reply

Thanks for the patch. can you just help explain why to use the SLASH and when not to. Didn't understand the direction "the use a regular expression".

Thanks

Reply

In Hide App Vendors, if you start and end something with a slash, you're specifying a regular expression (in which starting and ending slashes are not included), which I explain next. Otherwise, you're specifying a simple substring match.

A regular expression is a type of search string you specify if you want to perform any type of pattern matching beyond a simple substring test.

The following sites provide introductions and explain the different types of pattern matching regular expressions are capable of specifying:
Regular Expression Tutorial - Learn How to Use Regular Expressions
Regular expression - Wikipedia, the free encyclopedia

One thing to know is that there are basically two different families of regular expressions, "POSIX Basic" and "POSIX Extended". The first (or its bases) is the default for many Unix tools; the second is what the regex flavors implemented by Perl, JavaScript, and other languages are based on, and is also the basis for PCRE.

Hide App Vendors, of course, uses the JavaScript flavor. Any decent JavaScript reference (including Visibone's reference cards) can help you there.

Reply

Many thanks for this patch... it gets the job done without having the feel of someone else making the choice for me. Combine it with a friction point for app submissions and it 'should' return some control to the end users and cut back on spamming the catalog.

Let's hope Brighthouse and Dijit see where it's headed, and they don't start to adopt more advanced spam tactics (and this patch doesn't evolve into the addition of the ability to import .csv lists of spammers).

Reply

Awesome! I agree that I'd rather just not see these apps, but EPIC WORK on doing something about them to make them easier to pass over. Thank you a million times over for working on this!

Reply