Problem Turning off filter keys

I have a lazy habit of resting a finger onf the shift key when I'm pausing between words. If I do that for more than 8 seconds, XP asks if I want to turn on FilterKeys. It does this even if I un-check the "Use FilterKeys" box on the Accessibility settings. The box stays un-checked, but the feature doesn't turn off.

Solutions

1. Select the Two Shift keys simultaneously for around 8–10 seconds. Your problem will be solved. (self experience0.

2. To work around this problem, disable the Shortcut option for Filter keys:
    In Control Panel, double-click Accessibility Options.
    Under FilterKeys, click Settings.
    Under Keyboard shortcut, click to clear the Use shortcut check box

3. Disable all the stupid accessibility keys for good by importing these registry settings...

;----------------------------------
Windows Registry Editor Version 5.00

;Disable Sticky Keys
[HKEY_CURRENT_USER\Control Panel\Accessibility\StickyKeys]
"Flags"="506"

;Disable Filter Keys
[HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Response]
"Flags"="122"

;Disable Toggle Keys
[HKEY_CURRENT_USER\Control Panel\Accessibility\ToggleKeys]
"Flags"="58"
;-------------------------------------
Or download it here:
http://magicsynthesis.com/download/disablestupidkeys.reg

You can get more information from this post

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Different GUI Architectures

raphical user interfaces have become a familiar part of our software landscape, both as users and as developers. Looking at it from a design perspective they represent a particular set of problems in system design - problems that have led to a number of different but similar solutions.

Identifying common and useful patterns for application developers to use in rich-client development. Various designs in project reviews and also various designs that have been written in a more permanent way. Inside these designs are the useful patterns, but describing them is often not easy. Take Model-View-Controller as an example. It's often referred to as a pattern, but we don't find it terribly useful to think of it as a pattern because it contains quite a few different ideas. Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'. If this doesn't cause enough confusion you then get the effect of misunderstandings of MVC that develop through a system of Chinese whispers.

To some extent you can see this essay as a kind of intellectual history that traces ideas in UI design through multiple architectures over the years. Understanding architectures isn't easy, especially when many of them change and die. Tracing the spread of ideas is even harder, because people read different things from the same architecture. In particular the author done an exhaustive examination of the architectures I describe. What the author  have done is referred to common descriptions of the designs. If those descriptions miss things out, the author  utterly ignorant of that. So don't take the author  descriptions as an authoritative description of the architectures. Furthermore there things the author  left out or simplified if the author  didn't think they were particularly relevant. Read the authors explanation on Different GUI Architectures

 

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Points to remember while branching in version control systems

That's basically all you need to know, but here are some other pointers:

• When checking in to the branch, always put the branch name in the comment, so that people can easily tell where the change is happening.
• You can always make a branch from a revision in the past, even far in the past. I've often seen developers fret about needing to create a fixes branch before beginning work on new feature work. You don't have to. Create the fixes branch when you have a fix to put on it, and create it from the last shipped revision, no matter how long ago it was.
• Branches usually have finite lifetimes. For example, a feature branch is obsolete once it has been merged back to the trunk. To keep your branches directory manageable, you can delete the branch when you are done with it. You still have the history of the files in Subversion, and can even retrieve the full branch later if you need it. By deleting the obsolete branches, you let develeopers update from the branches directory without having to wade through unneeded files.
• Subversion's strange rule about needing two revision number even to merge a single changelist prompted me to create this one-line script file:

  svn merge -r`expr $2 - 1`:$2 ../trunk $1

  This lets me specify the branch directory and revision number, and it pulls a single changelist from the trunk to the branch.
• If you need to merge only part of a changeset, you have two choices: one is to not merge at all, but simply edit the files on the branch to match the changes made on the trunk. Alternately, you can merge the entire changeset, then manually revert the files you don't want, or edit files to undo unwanted changes. Remember, the merge command simply edits files in your working tree, so any changes you want to make, you can make by hand.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Different types of branching in version control systems

There are many different ways to use branches in software development. In fact, there are enough to fill a small book devoted to the subject. Don't worry about all of that. There are two branch types which solve most development problems:

• Fixes Branch: while feature work continues on the trunk, a fixes branch is created to hold the fixes to the latest shipped version of the software. This allows you to fix problems without having to wait for the latest crop of features to be finished and stabilized.
• Feature Branch: if a particular feature is disruptive enough or speculative enough that you don't want the entire development team to have to suffer through its early stages, you can create a branch on which to do the work.

These two types of branches have different use patterns involving branch point, merge policy, and lifetime. We'll examine them each in turn.

Fixes branches

A fixes branch (or maintenance branch) is used to apply bug fixes to a shipped version of the code. It lets you release follow-on versions of the software with bug fixes without having to incur the risk of shipping partially finished features.

Branching: the branch is created from the revision that actually shipped. This guarantees that no extra changes have accidentally slipped into your maintenance release. Use the -r argument to the svn copy command to ensure that you have the proper starting point. The branch should be named with the version number or revision number it branched from: fixes_v2_1, or fixes1234, for example.

Changes: For the most part, fixes are made on the trunk, then merged to the branch. This is because most fixes are appropriate to the trunk, and are chosen for inclusion in the maintenance release. Occaisionally, you may have to fix a bug in a maintenance release in a way that differs from how you would fix it on the trunk, because of changes in the trunk since you shipped. In that case, make the change directly on the fixes branch.

Merging: Only merge from the trunk to the branch. This is one of the reasons to make fixes on the trunk first. By keeping all the merging in only one direction (trunk to branch), you simplify the process and reduce the possibility of conflicts.

Merges will be done only for specific changesets, those with the bug fixes that should be included in the maintenance release. The merges will therefore be sparse, picking and choosing only those changes needed. The longer the branch is active, the greater possibility that a merge will not be possible because of conflicts introduced by missing changes from the trunk.

Lifetime: The lifetime of a fixes branch depends on your release model. If you are building a web site or other software that is "shipped" to only one place, the fixes branch will be obsoleted the next time you deploy the trunk. In a more traditional model, the fixes branch will have to stick around for a long time, until you end support for that version of the product.

A popular variant of the fix branch is a release branch: as development nears the point of releasing, a branch is created for the final polishing. This is fine to do so long as it doesn't violate the trunk-majority rule. If everyone is still working on polishing, and all of that work will be merged back to the trunk, there's no point branching yet.

Feature branches

A feature branch is used by developers creating a major feature, or one which is speculative, and may not be included in the product. Using one or more feature branch allows your developers to work independently of each other while still using Subversion as a way to share their work within the feature group.

The feature branch is generally kept up to date with the trunk as work progresses. Once the feature is done, the whole branch is merged back to the trunk.

Branching: the starting point of a features branch is less sensitive than with a fixes branch. When feature work begins, branch from the head, and dive in. Give the branch a descriptive name based on the feature, for example, 3d_ui.

Changes: the changes on the feature branch are whatever work has to happen to implement the feature. Make the changes on the branch and check them in.

Merging: the bulk of the merging on the feature branch will be to bring trunk changes over to keep the feature branch current with the trunk. These merges are a periodic maintenance task on the branch, for example, done once a week or so.

Subversion doesn't record the history of merging, so to do this periodic trunk update, you have to manually note which revision you are current with. For example, when the branch is created, note the revision:

$ svn copy http://svn.myrepo.com/trunk http://svn.myrepo.com/branches/3d_ui
Committed revision 1701.

When the time comes to merge the trunk over, you merge from there, including everything from the latest trunk revision merged, to the head:

$ svn update
At revision 1812.

$ svn merge -r1701:1812 /work/trunk /work/branches/3d_ui
U    3d_ui/source/hello.py
...

$ svn ci -m "[3d_ui] Merged the trunk from 1701 to 1812."
Sending        3d_ui/source/hello.py
...
Transmitting file data ..
Committed revision 1813.

After another interval of work (week, month, whatever is appropriate to your environment), you'll have to merge again to get the recent changes to the trunk. Again, you'll specify a revision range that takes only the changes you haven't already merged:

$ svn update
At revisioun 1865.

$ svn merge -r1812:1865 /work/trunk /work/branches/3d_ui
U    3d_ui/source/util.py
...

$ svn ci -m "[3d_ui] Merged the trunk from 1812 to 1865."
Sending        3d_ui/source/util.py
...
Transmitting file data ..
Committed revision 1866.

The checkin comments are important here, because they are the simplest way to keep track of what the latest merge revision was.

Eventually, the feature is done, and needs to be merged back to the trunk. Now you will merge all of the revisions from the branch point to the head from the branch back to the trunk:

$ svn update
At revision 1911.

$ svn merge -r1701:1911 /work/branches/3d_ui /work/trunk
U    /work/trunk/source/hologram.py
U    /work/trunk/source/volume.py
...

$ svn ci -m "Merged the 3d_ui branch back to the trunk."
Sending        /work/trunk/source/hologram.py
Sending        /work/trunk/source/volume.py
...
Transmitting file data ..
Committed revision 1912.

Lifecycle: at this point, the feature branch is done. You can go back to working on the trunk, or creating a new branch for the next big thing.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Branching in subversion

Subversion makes branching a simple process. If you set up your repository following the Subversion guidelines, you have a trunk/ directory and a branches/ directory. There's nothing magical about these directories, so if you don't have them, you can put your branch anywhere you like.

You'll use the svn copy command to copy the trunk as a branch. This doesn't actually copy any files until changes are made, so don't worry about disk space.

1. Decide on a name for the branch. It should be short and descriptive, and usable as a directory name. In these examples, it's "mybranch".
2. Use the svn copy command to create the branch in the repository by copying the trunk. The arguments are a destination path and a source path. The svn info command may be helpful to remind yourself what your repository path is. Here's an example that creates the mybranch branch from the trunk:

   $ svn copy http://svn.myrepo.com/trunk http://svn.myrepo.com/branches/mybranch
   Committed revision 1701.
   

   The change is committed immediately. Because this command uses repository paths, it changed the repository directly, with no effect on your working directory.
3. To get a working directory for your branch, you can simply go to your branches/ working directory and update to get the new branch:

   $ cd /work/branches
   $ svn up
   

   If you haven't checked out the branches directory, you can use the svn checkout command to get it or just the mybranch directory:

   $ mkdir /work/branches
   $ svn co http://svn.myrepo.com/branches/mybranch

That's it. Now you have a directory at /work/branches/mybranch where you can do whatever work you need to do.

The example above branched from the tip of the trunk (what Subversion calls HEAD). You can also branch from a particular past revision by specifying the -r argument with a revision number.

Working

Working with your branch is exactly the same as working on the trunk. You use svn update to get the latest code from the repository, you edit files, and you use svn commit to check in code to the repository.

Subversion doesn't make any fundamental distinction between branches and trunk. All changesets go into the same list of changesets, each with its own sequential revision number. This is because a Subversion revision number represents a revision of the entire repository, not of a single file.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Principles of branching in version control systems

Many developers are uneasy about branching and merging, even those who consider source control essential. It can be a very complicated process, but it doesn't have to be, and it is a very powerful way to manage development. Here's how to get started with branches in Subversion.

Principles

Branching produces a split in a code stream: different developers can be working in alternate universes of the same set of code. Changes are made independently to each stream. Merging brings changes back together to combine the streams. There are a number of reasons why you might want to use branches, and different reasons produce different kinds of branches.

Branching is a powerful tool in managing development and releases. There are many different styles of branching, but I've only ever needed two: Fixes and Features, which I'll describe below. These are simple, and fill 90% of the need for branching. Don't go overboard with elaborate branches. Purists will develop complex theories and algebras of branching, with baroque policies and criteria. It doesn't have to be complicated.

One recurring debate is over what goes on the trunk and what goes on the branch. How do you decide what work will happen on the trunk, and what will happen on the branch? Here is my rule: Branches are for the minority.

Using a branch is always more involved than using the trunk, so the trunk should be used by the majority, and the branch should belong to the minority. Subversion is easier than other source control systems in this regard, but the rule still holds: when trying to decide what goes on the trunk and what goes on the branch, put the code that most developers want on the trunk, and put the minority on the branch.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Tips to reduce your page load time

It is widely accepted that fast-loading pages improve the user experience. In recent years, many sites have started using AJAX techniques to reduce latency. Rather than round-trip through the server retrieving a completely new page with every click, often the browser can either alter the layout of the page instantly or fetch a small amount of HTML, XML, or javascript from the server and alter the existing page. In either case, this significantly decreases the amount of time between a user click and the browser finishing rendering the new content.

However, for many sites that reference dozens of external objects, the majority of the page load time is spent in separate HTTP requests for images, javascript, and stylesheets. AJAX probably could help, but speeding up or eliminating these separate HTTP requests might help more, yet there isn't a common body of knowledge about how to do so.

Try some of the following:

• Turn on HTTP keepalives for external objects. Otherwise you add an extra round-trip for every HTTP request. If you are worried about hitting global server connection limits, set the keepalive timeout to something short, like 5-10 seconds. Also look into serving your static content from a different webserver than your dynamic content. Having thousands of connections open to a stripped down static file webserver can happen in like 10 megs of RAM total, whereas your main webserver might easily eat 10 megs of RAM per connection.

• Load fewer external objects. Figure out how to globally reference the same one or two javascript files and one or two external stylesheets instead of many; try preprocessing them when you publish them. If your UI uses dozens of tiny GIFs all over the place, consider switching to CSS, which tends to not need so many of these.

• If your users regularly load a dozen or more uncached or uncachable objects per page, consider evenly spreading those objects over four hostnames. This usually means your users can have 4x as many outstanding connections to you. Without HTTP pipelining, this results in their average latency dropping to about 1/4 of what it was before.

  Evenly spreading your images over four hostnames is most easily done with a hash function, like MD5. Rather than loading all of your objects from http://static.example.com/, create four hostnames (e.g. static0.example.com, static1.example.com, static2.example.com, static3.example.com) and use two bits from an MD5 of the image path to select between them.

  Beware that each additional hostname adds the overhead of an extra DNS lookup and an extra TCP three-way handshake. If your users have pipelining enabled or a given page loads fewer than around a dozen objects, they will see no benefit from the increased concurrency and the site may actually load more slowly. The benefits only become apparent on pages with larger numbers of objects. Be sure to measure the difference seen by your users if you implement this.

• Allow static images, stylesheets, and javascript to be cached by the browser. This won't help the first page load for a new user, but can substantially speed up subsequent ones.

  Set an Expires header on everything you can, with a date days or even months into the future. This tells the browser it is okay to not revalidate on every request, which can add latency of at least one round-trip per object per page load for no reason.

  Instead of relying on the browser to revalidate its cache, if you change an object, change its URL. One simple way to do this for static objects if you have staged pushes is to have the push process create a new directory named by the build number, and teach your site to always reference objects out of the current build's base URL. (Instead of <img src="http://example.com/logo.gif"> you'd use <img src="http://example.com/build/1234/logo.gif">. When you do another build next week, all references change to <img src="http://example.com/build/1235/logo.gif">.) This also nicely solves problems with browsers sometimes caching things longer than they should -- since the URL changed, they think it is a completely different object.

  If you conditionally gzip HTML, javascript, or CSS, you probably want to add a "Cache-Control: private" if you set an Expires header. This will prevent problems with caching by proxies that won't understand that your gzipped content can't be served to everyone. (The Vary header was designed to do this more elegantly, but you can't use it because of IE brokenness.)

  For anything where you always serve the exact same content when given the same URL (e.g. static images), add "Cache-Control: public" to give proxies explicit permission to cache the result and serve it to different users. If a local cache has the content, it is likely to have much less latency than you; why not let it serve your static objects if it can?

  Avoid the use of query params in image URLs, etc. At least the Squid cache refuses to cache any URL containing a question mark by default. I've heard rumors that other things won't cache those URLs at all, but I don't have more information.

• Minimize HTTP request size. Often cookies are set domain-wide, which means they are also unnecessarily sent by the browser with every image request from within that domain. What might've been a 400 byte request for an image could easily turn into 1000 bytes or more once you add the cookie headers. If you have a lot of uncached or uncachable objects per page and big, domain-wide cookies, consider using a separate domain to host static content, and be sure to never set any cookies in it.

• Minimize HTTP response size by enabling gzip compression for HTML and XML for browsers that support it. For example, the 17k document you are reading takes 90ms of the full downstream bandwidth of a user on 1.5Mbit DSL. Or it will take 37ms when compressed to 6.8k. That's 53ms off of the full page load time for a simple change. If your HTML is bigger and more redundant, you'll see an even greater improvement.

  If you are brave, you could also try to figure out which set of browsers will handle compressed Javascript properly. (Hint: IE4 through IE6 asks for its javascript compressed, then breaks badly if you send it that way.) Or look into Javascript obfuscators that strip out whitespace, comments, etc and usually get it down to 1/3 to 1/2 its original size.

• Consider locating your small objects (or a mirror or cache of them) closer to your users in terms of network latency. For larger sites with a global reach, either use a commercial Content Delivery Network, or add a colo within 50ms of 80% of your users and use one of the many available methods for routing user requests to your colo nearest them.

• Regularly use your site from a realistic net connection. Convincing the web developers on my project to use a "slow proxy" that simulates bad DSL in New Zealand (768Kbit down, 128Kbit up, 250ms RTT, 1% packet loss) rather than the gig ethernet a few milliseconds from the servers in the U.S. was a huge win. We found and fixed a number of usability and functional problems very quickly.

• (Optional) Petition browser vendors to turn on HTTP pipelining by default on new browsers. Doing so will remove some of the need for these tricks and make much of the web feel much faster for the average user. (Firefox has this disabled supposedly because some proxies and some versions of IIS choke on pipelined requests. But there are workarounds.)

The above list covers improving the speed of communication between browser and server and can be applied generally to many sites, regardless of what web server software they use or what language the code behind their site is written in.

The techniques of measurement and experimentation can be applied to other sources of latency. For example, try benchmarking common pages on your site with ab, which comes with the Apache webserver. If your server is taking longer than 5 or 10 milliseconds to generate a page, you should make sure you have a good understanding of where it is spending its time.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Using firefox browser without mouse

Did you ever want to use your browser without needing a mouse? Most browsers have useful keyboard shortcuts that may help you do basic tasks like opening a new tab or entering a web address. But how do you move from one page to another one without clicking on links.

Firefox has a simple trick: press ' (single quote) and you can search through the links from a page by typing a string in the small box from the bottom of the window. So you could type the first characters from the anchor and when the link you want to open has focus, press enter. But what if the page has only links with this anchor "click here"? And what about buttons and image links?

Hit-a-Hint is an extension for Firefox that wants to solve this problem. The idea is that you press a magic key and, after that, each link from the page has a unique combination. All you have to do is press the keys attached to that link. Fortunately, the extension uses numbers, so in most cases, you'll type only one or two numeric keys.

To install this extension, visit this page.

After you restart your browser, you can use the extension this way: press space (space is the magic key) and then one of the unique numbers next your favorite link, while still pressing space. Then release the space key. To open the page in a new tab, press Ctrl before releasing space key.

If you don't like keeping space key pressed, you can just press h, type the numeric combination, and then press enter.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Microsoft Atlas beta release needs a new development approach with Ajax

he new Beta of Atlas has been released and that it isn't called Atlas anymore but ASP.NET Ajax. Lots of changes have been introduced, including the renaming of the $() function to $get() to allow it to work with other Javascript libraries. Maybe it's not quite Beta quality, says Rick Strahl in his recent post entitled More MS Ajax Pain.

The truth is we're all still learning how to build, debug, test and support Ajax applications. See the various development tips from Ajax framework developers on how to debug applications festooned with Ajax widgets. New abstraction, inderection and other plumbing will make it easier to develop, but harder to debug and productivity is bound to go down before it goes up. It's been a long time since I've had any direct insight into Microsoft's internal development practices, but I have to believe they are struggling to find qualified Javascript programmers just like everyone else, just as I'm sure they're struggling to extend their unit, system and regression testing processes to cover the far more intricate logic on the browser.

At the end of the day, it looks to me that MS's approach of incrementally improving ASP.NET will be just good enough to allow them to capture the biggest market share for .NET Ajax. But TibCo GI, Echo2 (when the .NET version comes out), etc., all look to have more interesting offerings, IMHO, even for big corporate players who want to stick to .NET, especially if the productivity of their developers goes up.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Find good feeds at Feeds that matter

Want to find a few good feeds? Try Feeds That Matter, an interesting grouping of publicly listed feeds at Bloglines:

There are about 83K publicly listed users on bloglines and they have a combined 2,786,687 feed subscriptions. Roughly 35% of these publicly listed users organize their feeds into folders. On an average there are about 20 feeds per folder. By analyzing this data and combining merging folders that are very similar, we have come up with an automatic way of creating a taxonomy of popular topics and make it easy to find feeds that are most relevant to that topic.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Google Ajax search code in your website

The Google AJAX Search API is “an experimental API that lets you integrate a dynamic Google search module into your web pages so your users can mash up Google search results with other content on your site or add search results clippings to their own content.”

The AJAX Search API is currently in Version 0.1 and its an experiment designed to get developer feedback. Version 1.0 to be launched later will likely contain advertising. To use the API, you must sign up for a Google AJAX Search API key, which you’ll include in the URL with which you access the API.

The AJAX Search API is available for all sites that are accessible to consumers without charge. The Google AJAX Search API is currently available on Firefox, Safari, and IE 6. Put Google AJAX Search on your web site.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Feedpass an easy rss feed subscription service

Feedpass offers to provide a single page allowing your website visitors to easily subscribe to your blog RSS feed using all services possible.

Each visitor has their own favourite way of reading blogs. Some use rss aggregators like Bloglines, MyYahoo, Rojo etc. Some like rss to email delivery of your posts using services like rmail, rssfwd or feedblitz. It provides quick links to all these services to let readers subscribe to your blog easily. Then it lists the headlines of the most recent posts from your feed and lets users bookmarks your posts on social bookmarking tools like del.icio.us, furl, spurl, etc..

Feedpass lets you earn extra money from your feedpass pages if you add your Google AdSense id code. The targeted contextual ads which load on that page will display ads with your Google adsense id and will earn you money when people click on them.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

With Gickr create your animated gifs easily

You had to do a little bit of work to create your own animated GIFs, but not anymore thanks to Gickr. Gickr works by taking images from (where else?) Flickr. If you already have a Flickr account, you can enter your username and a photo tag, and choose images which you’d like to use to create your animated GIF. Don’t have a Flickr account? No problem! Gickr lets you upload up to 10 different images to create your animated GIF. The best thing about Gickr is that it’s free and there is no registration required.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Use L8ter to monitor down time your website

 As your site grows in popularity you are bound to face some downtime with your site, particularly if you end up getting dugg or slashdotted. Once your site reaches its bandwidth limit, users will start seeing error messages and may end up forgetting about your site and not coming now. There is a new service cleverly called L8ter which should help out. If you find a site that’s down, but that you’d like to come back to, simply head over to L8ter and enter the link of the site as well as your e-mail address. L8ter will then query the site until it comes back up, then inform you, via e-mail so you can go back to it and check it out. Additionally, L8ter offers a Firefox extension called Monitor with L8ter, so you can monitor a site right from your browser. Like all great things, it’s 100% free.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Use Showcase extension to manage firefox tabs easily

Showcase is one of those Firefox extensions which aren’t essential, but which add a little bit of eye candy and make the browser just a little bit more useful. If you have browsing habits like mine, then chances are that you keep at least 5, sometimes 10-20+, tabs open at once. Managing such a large number of tabs can be a little daunting, but not with Showcase.

Showcase shows you thumbnail images of all open tabs. If you want to switch to a particular tab, just click on its thumbnail and you’re taken there, or you can select multiple tabs by holding CTRL on your keyboard and selecting those tabs.

Showcase can show tabs in a tab, a new window, or in the Firefox sidebar. The extension is free and open-source and should work all Firefox version up to 2.0.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com

Defend your computer with Microsoft Defender

Microsoft Defender is a fantastic application and actually works quite well, maybe due in part to the fact that it wasn’t developed entirely in-house, as Defender is the result of Microsoft buying out antispyware company GIANT. Regardless, Defender is quite polished, and for the months that I used the product, I never had to worry about any kind of spyware invading my system. Thanks to its integration with Windows, Defender also blocks popups and keeps you informed of security updates, all for free.

About Microsoft AntiSpyware back in May of last year, while the product was still in early beta stages. Since then, Microsoft has changed the name of the application from AntiSpyware to Defender, and after many, many months in closed beta, has finally released it to the public.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com