Index by title

This milestone if the first release candiate.
At this stage, no new features can be planned for 3.0, only bug fixes may be done

FAQ

When will GeekTool 3 be release
I hope to release a first Release Candidate around mid-august 2009, it depends on bug reports I receive, so far, no big problems are detected

Should I be concerned about the memory GeekTool uses ?
Yes and no.

Look at activity monitor, and check RSIZE number. It should be reasonable, since this is the real memory the application is using for itself.

Don't pay attention to high VSIZE. From mikeash.com :

(For 64-bit programs, the virtual address space is virtually unlimited, and so this column is of little use. For example, garbage collected apps in 64-bit immediately allocate a 64GB chunk of virtual address space just to make the accounting easier. This has no bearing on your actual memory usage and is completely harmless, although it tends to freak out users who go groveling around Activity Monitor.)

There is a bug, what should I do ?
Report it ! If you have a problem with GeekTool, please consult the issue tracking system to see if somebody else already reported that issue.
If not, please do.

What can I do with GeekTool ?
Take a look at the Tips & Trick forum for script samples and usages

Display twitter feed from GeekTool search (or whatever you like)

Put this command in a new Shell Geeklet command :


Replace q=geektool with q=<any keyword>

[raw-attachment:"GeekTool feed.gset" GeekTool feed.gset]





How you can help improving Geektool



	
Users and testers are the best friends of the developer, because each one uses the product their own way.



	
That's why I need you to report bugs and request features on this site. This is the only centralized point of collection for anything wrong (or good to be) with Geektool 3



	
So please, use this page to create bug reports or feature requests.



	
Bug reporting



	
If you note a bad behavior, provide the best description you can about the context, the items used (Operating System version, which geeklet, which command, image URL etc...)



	
Pplease provide the release of Geektool, displayed in preference pane, and the crash report, if applicable, found in ~/Library/Logs/CrashReporter/GeekTool*



	
In any case, any output related to Geektool in Console.app is usefull too



	
Attach everything with the bug report and I shall have the informations needed to fix the problem



	
Feature request



	
Open a ticket with type "Feature" and a description, do not take care of the milestone, release,assignment field etc...






Wiki Page Templates



	
_(since 0.11



	
The default content for a new wiki page can be chosen from a list of page templates.



	
That list is made up from all the existing wiki pages having a name starting with PageTemplates/.

The initial content of a new page will simply be the content of the chosen template page, or a blank page if the special (blank page) entry is selected. When there's actually no wiki pages matching that prefix, the initial content will always be the blank page and the list selector will not be shown (i.e. this matches the behavior we had up to now).



	
To create a new template, simply create a new page having a name starting with PageTemplates/.



	
(Hint: one could even create a !PageTemplates/Template for facilitating the creation of new templates!)



	
Available templates:

TitleIndex(PageTemplates/)



	
----

See also: TracWiki






Jke used GeekTool a really clever way to output random symbol character on his desktop, really nice effect :



	
"So here is a quick way to do it :



* Create a shell geeklet
* Use this command :


* Set some fancy font. In his original script, Jke used "Chippies", but is not free nor standard, so I used "Type Embellishments One LET Plain" 

Here is a gset you can quickly try :

[raw-attachment:"Random symbol.gset" Random symbol.gset":http://jakefowler.com/movies/Geektool.mov]





Here is a nice way to show current tickets on the desktop... using GeekTool of course :




curl -s -k https://projects.tynsoe.org/projects/geektool3/report/1|sed -n -e '/class=\"ticket\"/N;//N;//N;//N;s/.*\#\([0-9]*\).*title=\"View ticket\"[^>]*>\([^<]*\)<.*/\1 \2/p'|sort









	
Random character



	
Get a random character to be used with a fancy/dingbats font as ornament



	
Using AppleScript (by Flip)




-- Save as script and call from GeekTool with "osascript path_to_the_script" 
set ls to "abcdefgh" -- characters to use (find them in TextEdit using the font you want then copy/paste)
set n to count items of ls
set theSeed to do shell script "head -n 1 /dev/random" 
set x to random number from 1 to n with seed theSeed
return (item x of ls)



	
Using shell




echo "\x@echo \"obase=16;$((25*$RANDOM/32767+97))\"|bc@" 



Ok... mmm... This one may require some explanation :-)

This one returns a lowercase letter from a to z.

97 refers to the first ascii code you want (see man ascii)

25 is last ascii code - first ascii code (that is last ascii code - 97)

	
Using Perl* (by Brandon)




perl -e '@a=qw(a b c d e);print $a[rand($#a)]'



	
Twitter feeds



	
Friends timeline




curl --basic --user user:password http://twitter.com/statuses/friends_timeline.rss 2> /dev/null | grep title | sed 's/.*<title>//;s/<\/title>//' | perl -MHTML::Entities -ne 'binmode(STDOUT, ":utf8");print decode_entities($_)'



	
Search query




curl --basic http://search.twitter.com/search.atom?q=geektool 2> /dev/null | grep title | sed 's/.*<title>//;s/<\/title>//' | perl -MHTML::Entities -ne 'binmode(STDOUT, ":utf8");print decode_entities($_)'



	
Calendar



	
Simple Calendar



Change the LANG to suit your locale (get it in terminal by typing "echo $LANG")


export LANG=fr_FR;cal | sed "s/ $(date +%e) / $(echo  '\033[40m\033[1;31m')$(date +%e)$(echo  '\033[0m') /" 



Alternatively, you can mark the current day this way (by Chris Ferrara) :


export LANG=fr_FR;cal | sed "s/^/ /;s/$/ /;s/ $(date +%e) / $(date +%e | sed 's/./#/g') /" 







Fine grained permissions



	
Before Trac 0.11, it was only possible to define fine-grained permissions checks on the repository browser sub-system.



	
Since 0.11, there's a general mechanism in place that allows custom permission policy plugins to grant or deny any action on any kind of Trac resources, even at the level of specific versions of such resources.



	
Permission Policies



	
AuthzPolicy



An example policy based on an Authz-style system has been added. See

[trac:source:branches/0.11-stable/sample-plugins/permissions/authz_policy.py authz_policy.py] for details (current version requires >= Python 2.4). (See also [trac:source:branches/0.11-stable/sample-plugins/permissions sample-plugins/permissions] for more samples.)

 - Install ConfigObj (required).

 - Copy authz_policy.py into your plugins directory.

 - Put a authzpolicy.conf file somewhere (preferably on a secured location on the server, not readable for others than the webuser.

 - Update your trac.ini:


[trac]
...
permission_policies = AuthzPolicy, DefaultPermissionPolicy, LegacyAttachmentPolicy

[authz_policy]
authz_file = /some/trac/env/conf/authzpolicy.conf

[components]
...
authz_policy = enabled



	
Note that the order in which permission policies are specified is quite critical, 

as policies will be examined in the sequence provided.



	
A policy will return either True, False or None for a given permission check.

Only if the return value is None will the next permission policy be consulted.

If no policy explicitly grants the permission, the final result will be False 

(i.e. no permission).



For example, if the authz_file contains:


WikiStart@*
* = WIKI_VIEW

PrivatePage@*
john = WIKI_VIEW
* =



and the default permissions are set like this:


john           WIKI_VIEW
jack           WIKI_VIEW
# anonymous has no WIKI_VIEW



	
Then: 

 - All versions of WikiStart will be viewable by everybody (including anonymous)

 - PrivatePage will be viewable only by john

 - other pages will be viewable only by john and jack



	
mod_authz_svn-like permission policy



	
At the time of this writing, the old fine grained permissions system from Trac 0.10 and before used for restricting access to the repository has not yet been converted to a permission policy component, but from the user point of view, this makes little if no difference.



	
That kind of fine-grained permission control needs a definition file, which is the one used by Subversion's mod_authz_svn. 

More information about this file format and about its usage in Subversion is available in the Subversion Book.



Example:


[/]
* = r

[/branches/calc/bug-142]
harry = rw
sally = r

[/branches/calc/bug-142/secret]
harry =



	


	
Trac Configuration





<pre>
[trac]
authz_file = /path/to/svnaccessfile
</pre>

if you want to support the use of the @[@_modulename_@:/@_some_@/@_path_@]@ syntax within the @authz_file@, add 

<pre>
authz_module_name = modulename
</pre>

where _modulename_ refers to the same repository indicated by the @repository_dir@ entry in the @[trac]@ section.

*Note:* Usernames inside the Authz file +must+ be the same as those used inside trac. 

h4. Subversion Configuration

The same access file is typically applied to the corresponding Subversion repository using an Apache directive like this:
<pre>
<Location /repos>
  DAV svn
  SVNParentPath /usr/local/svn

  # our access control policy
  AuthzSVNAccessFile /path/to/svnaccessfile
</Location>
</pre>

For information about how to restrict access to entire projects in a multiple project environment see [trac:wiki:TracMultipleProjectsSVNAccess]

h2. Getting TracFineGrainedPermissions to work

Don't forget to restart Trac engine to apply new configuration if you are running tracd standalone server.

----
See also: TracPermissions
http://trac-hacks.org/wiki/FineGrainedPageAuthzEditorPlugin for a simple editor plugin.





Trac and mod_wsgi



	
Important note: Please use either version 1.3 or 2.3 or later of mod_wsgi. Version 2.0 has problems with downloading attachments (see [trac:#7205 #7205]).



	
mod_wsgi is an Apache module for running WSGI-compatible Python applications directly on top of Apache:



	
The mod_wsgi adapter is an Apache module that provides a WSGI compliant interface for hosting Python based web applications within Apache. The adapter is written completely in C code against the Apache C runtime and for hosting WSGI applications within Apache provides significantly better performance than using existing WSGI adapters for mod_python or CGI.



	
It is already possible to run Trac on top of mod_wsgi. This can be done by writing the following application script, which is just a Python file, though usually saved with a .wsgi extension).




import os

os.environ['TRAC_ENV'] = '/usr/local/trac/mysite'
os.environ['PYTHON_EGG_CACHE'] = '/usr/local/trac/mysite/eggs'

import trac.web.main
application = trac.web.main.dispatch_request





<pre>
<pre>

If you have installed trac and eggs in a path different from the standard one you should add that path by adding the following code on top of the wsgi script:
<pre>
import site
site.addsitedir('/usr/local/trac/lib/python2.4/site-packages')
</pre>
Change it according to the path you installed the trac libs at.

After you've done preparing your wsgi-script, add the following to your httpd.conf.

<pre>
WSGIScriptAlias /trac /usr/local/trac/mysite/apache/mysite.wsgi

<Directory /usr/local/trac/mysite/apache>
    WSGIApplicationGroup %{GLOBAL}
    Order deny,allow
    Allow from all
</Directory>
</pre>

<pre>

To test the setup of Apache, mod_wsgi and Python itself (ie. without involving Trac and dependencies), this simple wsgi application can be used to make sure that requests gets served (use as only content in your .wsgi script):

<pre>
def application(environ, start_response):
        start_response('200 OK',[('Content-type','text/html')])
        return ['<html><body>Hello World!</body></html>']
</pre>

See also the mod_wsgi "installation instructions":http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac for Trac.

For troubleshooting tips, see the [TracModPython#Troubleshooting mod_python troubleshooting] section, as most Apache-related issues are quite similar, plus discussion of potential "application issues":http://code.google.com/p/modwsgi/wiki/ApplicationIssues when using mod_wsgi.

h2. Trac with PostgreSQL

When using the mod_wsgi adapter with multiple Trac instances and PostgreSQL (or MySQL?) as a database back-end the server can get a lot of open database connections. (and thus PostgreSQL processes)

A workable solution is to disabled connection pooling in Trac. This is done by setting poolable = False in trac.db.postgres_backend on the PostgreSQLConnection class.

But it's not necessary to edit the source of trac, the following lines in trac.wsgi will also work:

<pre>
import trac.db.postgres_backend
trac.db.postgres_backend.PostgreSQLConnection.poolable = False
</pre>

Now Trac drops the connection after serving a page and the connection count on the database will be kept minimal.

h2. Getting Trac to work nicely with SSPI and 'Require Group'

If like me you've set Trac up on Apache, Win32 and configured SSPI, but added a 'Require group' option to your apache configuration, then the SSPIOmitDomain option is probably not working.  If its not working your usernames in trac are probably looking like 'DOMAIN\user' rather than 'user'.

This WSGI script 'fixes' things, hope it helps:
<pre>
import os
import trac.web.main

os.environ['TRAC_ENV'] = '/usr/local/trac/mysite'
os.environ['PYTHON_EGG_CACHE'] = '/usr/local/trac/mysite/eggs'

def application(environ, start_response):
    if "\\" in environ['REMOTE_USER']:
        environ['REMOTE_USER'] = environ['REMOTE_USER'].split("\\", 1)r1
    return trac.web.main.dispatch_request(environ, start_response)
</pre>
----
See also:  TracGuide, TracInstall, [[TracModWSGI|ModWSGI] [wikiTracFastCgi FastCGI] [wikiTracModPython ModPython] [tracTracNginxRecipe TracNginxRecipe]]





Trac Navigation



	
Starting with Trac 0.11, it is now possible to customize the main and meta navigation entries in some basic ways.



	
The new [mainnav] and [metanav] configuration sections can now be used to customize the text and link used for the navigation items, or even to disable them.



	
[mainnav] corresponds to the main navigation bar, the one containing entries such as Wiki, Timeline, Roadmap, Browse Source and so on. This navigation bar is meant to access the default page of the main modules enabled in Trac and accessible for the current user.



	
[metanav] corresponds to the meta navigation bar, by default positioned above the main navigation bar and below the Search box. It contains the Log in, Logout, Help/Guide etc. entries. This navigation bar is meant to access some global information about the Trac project and the current user.



	
Note that it is still not possible to customize the contextual navigation bar, i.e. the one usually placed below the main navigation bar.



	
Example



	
In the following example, we rename the link to the Wiki start "Home", and hide the "Help/Guide" link. 

We also make the "View Tickets" entry link to a specific report.



Relevant excerpt from the TracIni:


[mainnav]
wiki.label = Home
tickets.href = /report/24

[metanav]
help = disabled



	
----

See also: TracInterfaceCustomization, and the TracHacks:NavAddPlugin or TracHacks:MenusPlugin (still needed for adding entries)






The Trac Ticket Workflow System



	
TracGuideToc



	
The Trac issue database provides a configurable workflow.



	
The Default Ticket Workflow 

 Environments upgraded from 0.10 =

When you run trac-admin &lt;env&gt; upgrade, your trac.ini will be modified to include a [ticket-workflow] section.

The workflow configured in this case is the original workflow, so that ticket actions will behave like they did in 0.10.



	
Graphically, that looks like this:



	
../common/guide/original-workflow.png)



	
There are some significant "warts" in this; such as accepting a ticket sets it to 'assigned' state, and assigning a ticket sets it to 'new' state.  Perfectly obvious, right?

So you will probably want to migrate to "basic" workflow; [trac:source:trunk/contrib/workflow/migrate_original_to_basic.py contrib/workflow/migrate_original_to_basic.py] may be helpful.



	
Environments created with 0.11



	
When a new environment is created, a default workflow is configured in your trac.ini.  This workflow is the basic workflow (described in basic-workflow.ini), which is somewhat different from the workflow of the 0.10 releases.



	
Graphically, it looks like this:



	
../common/guide/basic-workflow.png)



	
Additional Ticket Workflows



	
There are several example workflows provided in the Trac source tree; look in [trac:source:trunk/contrib/workflow contrib/workflow] for .ini config sections.  One of those may be a good match for what you want. They can be pasted into the [ticket-workflow] section of your trac.ini file.



	
Here are some diagrams of the above examples.



	
Basic Ticket Workflow Customization



	
Note: Ticket "statuses" or "states" are not separately defined. The states a ticket can be in are automatically generated by the transitions defined in a workflow. Therefore, creating a new ticket state simply requires defining a state transition in the workflow that starts or ends with that state.



Create a [ticket-workflow] section in trac.ini.

Within this section, each entry is an action that may be taken on a ticket. 

For example, consider the accept action from simple-workflow.ini:


accept = new,accepted -> accepted
accept.permissions = TICKET_MODIFY
accept.operations = set_owner_to_self



The first line in this example defines the accept action, along with the states the action is valid in (new and accepted), and the new state of the ticket when the action is taken (accepted).

The accept.permissions line specifies what permissions the user must have to use this action.

The accept.operations line specifies changes that will be made to the ticket in addition to the status change when this action is taken.  In this case, when a user clicks on accept, the ticket owner field is updated to the logged in user.  Multiple operations may be specified in a comma separated list.

The available operations are:

 - del_owner -- Clear the owner field.

 - set_owner -- Sets the owner to the selected or entered owner.

   - actionname@.set_owner@ may optionally be set to a comma delimited list or a single value.

 - set_owner_to_self -- Sets the owner to the logged in user.

 - del_resolution -- Clears the resolution field

 - set_resolution -- Sets the resolution to the selected value.

   - actionname@.set_resolution@ may optionally be set to a comma delimited list or a single value.


Example:

resolve_new = new -> closed
resolve_new.name = resolve
resolve_new.operations = set_resolution
resolve_new.permissions = TICKET_MODIFY
resolve_new.set_resolution = invalid,wontfix



 - leave_status -- Displays "leave as <current status>" and makes no change to the ticket.

Note: Specifying conflicting operations (such as set_owner and del_owner) has unspecified results.


resolve_accepted = accepted -> closed
resolve_accepted.name = resolve
resolve_accepted.permissions = TICKET_MODIFY
resolve_accepted.operations = set_resolution



	
In this example, we see the .name attribute used.  The action here is resolve_accepted, but it will be presented to the user as resolve.



For actions that should be available in all states, * may be used in place of the state.  The obvious example is the leave action:


leave = * -> *
leave.operations = leave_status
leave.default = 1



This also shows the use of the .default attribute.  This value is expected to be an integer, and the order in which the actions are displayed is determined by this value.  The action with the highest .default value is listed first, and is selected by default.  The rest of the actions are listed in order of decreasing .default values.

If not specified for an action, .default is 0.  The value may be negative.

	
There are a couple of hard-coded constraints to the workflow.  In particular, tickets are created with status new, and tickets are expected to have a closed state.  Further, the default reports/queries treat any state other than closed as an open state.



	
While creating or modifying a ticket workfow, contrib/workflow/workflow_parser.py may be useful.  It can create .dot files that GraphViz understands to provide a visual description of the workflow.



This can be done as follows (your install path may be different).


cd /var/local/trac_devel/contrib/workflow/
sudo ./showworkflow /srv/trac/PlannerSuite/conf/trac.ini



And then open up the resulting trac.pdf file created by the script (it will be in the same directory as the trac.ini file).

	
After you have changed a workflow, you need to restart apache for the changes to take effect. This is important, because the changes will still show up when you run your script, but all the old workflow steps will still be there until the server is restarted.



	
Example: Adding optional Testing with Workflow



	
By adding the following to your [ticket-workflow] section of trac.ini you get optional testing.  When the ticket is in new, accepted or needs_work status you can choose to submit it for testing.  When it's in the testing status the user gets the option to reject it and send it back to needs_work, or pass the testing and send it along to closed.  If they accept it then it gets automatically marked as closed and the resolution is set to fixed.  Since all the old work flow remains, a ticket can skip this entire section.




testing = new,accepted,needs_work,assigned,reopened -> testing
testing.name = Submit to reporter for testing
testing.permissions = TICKET_MODIFY

reject = testing -> needs_work
reject.name = Failed testing, return to developer

pass = testing -> closed
pass.name = Passes Testing
pass.operations = set_resolution
pass.set_resolution = fixed



	
Example: Add simple optional generic review state



	
Sometimes Trac is used in situations where "testing" can mean different things to different people so you may want to create an optional workflow state that is between the default workflow's assigned and closed states, but does not impose implementation-specific details. The only new state you need to add for this is a reviewing state. A ticket may then be "submitted for review" from any state that it can be reassigned. If a review passes, you can re-use the resolve action to close the ticket, and if it fails you can re-use the reassign action to push it back into the normal workflow.



	
The new reviewing state along with its associated review action looks like this:




review = new,assigned,reopened -> reviewing
review.operations = set_owner
review.permissions = TICKET_MODIFY



	
Then, to integrate this with the default Trac 0.11 workflow, you also need to add the reviewing state to the accept and resolve actions, like so:




accept = new,reviewing -> assigned
[…]
resolve = new,assigned,reopened,reviewing -> closed



	
Optionally, you can also add a new action that allows you to change the ticket's owner without moving the ticket out of the reviewing state. This enables you to reassign review work without pushing the ticket back to the new status.




reassign_reviewing = reviewing -> *
reassign_reviewing.name = reassign review
reassign_reviewing.operations = set_owner
reassign_reviewing.permissions = TICKET_MODIFY



	
The full [ticket-workflow] configuration will thus look like this:




[ticket-workflow]
accept = new,reviewing -> assigned
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
leave = * -> *
leave.default = 1
leave.operations = leave_status
reassign = new,assigned,reopened -> new
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
reopen = closed -> reopened
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve = new,assigned,reopened,reviewing -> closed
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY
review = new,assigned,reopened -> reviewing
review.operations = set_owner
review.permissions = TICKET_MODIFY
reassign_reviewing = reviewing -> *
reassign_reviewing.operations = set_owner
reassign_reviewing.name = reassign review
reassign_reviewing.permissions = TICKET_MODIFY



	
Example: Limit the resolution options for a new ticket



	
The above resolve_new operation allows you to set the possible resolutions for a new ticket.  By modifying the existing resolve action and removing the new status from before the -> we then get two resolve actions.  One with limited resolutions for new tickets, and then the regular one once a ticket is accepted.




resolve_new = new -> closed
resolve_new.name = resolve
resolve_new.operations = set_resolution
resolve_new.permissions = TICKET_MODIFY
resolve_new.set_resolution = invalid,wontfix,duplicate

resolve = assigned,accepted,reopened -> closed
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY



	
Advanced Ticket Workflow Customization



	
If the customization above is not extensive enough for your needs, you can extend the workflow using plugins.  These plugins can provide additional operations for the workflow (like code_review), or implement side-effects for an action (such as triggering a build) that may not be merely simple state changes.  Look at [trac:source:trunk/sample-plugins/workflow sample-plugins/workflow] for a few simple examples to get started.



	
But if even that is not enough, you can disable the ConfigurableTicketWorkflow component and create a plugin that completely replaces it.



	
Adding Workflow States to Milestone Progress Bars



	
If you add additional states to your workflow, you may want to customize your milestone progress bars as well.  See [TracIni#milestone-groups-section TracIni].



	
some ideas for next steps



	
New enhancement ideas for the workflow system should be filed as enhancement tickets against the ticket system component.  If desired, add a single-line link to that ticket here.  Also look at the [th:wiki:AdvancedTicketWorkflowPlugin] as it provides experimental operations.



	
If you have a response to the comments below, create an enhancement ticket, and replace the description below with a link to the ticket.



	
    
	
  • the "operation" could be on the nodes, possible operations are:
	
      
	
    • preops: automatic, before entering the state/activity
      • 
		
    • postops: automatic, when leaving the state/activity
      • 
		
    • actions: can be chosen by the owner in the list at the bottom, and/or drop-down/pop-up together with the default actions of leaving the node on one of the arrows.
      
This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.
      • 
	
    • 
	



	
    
	
  • operations could be anything: sum up the time used for the activity, or just write some statistical fields like 
    
A workflow plugin can add an arbitrary workflow operation, so this is already possible.
    • 
	



	
    
	
  • set_actor should be an operation allowing to set the owner, e.g. as a "preop":
	
      
	
    • either to a role, a person
      • 
		
    • entered fix at define time, or at run time, e.g. out of a field, or select.
      
This is either duplicating the existing set_owner operation, or needs to be clarified.
      • 
	
    • 
	



	
    
	
  • Actions should be selectable based on the ticket type (different Workflows for different tickets)
    
Look into the [th:wiki:AdvancedTicketWorkflowPlugin]'s triage operation.
    • 
	






Welcome to Geektool 3.0 Development page



	
Geektool is a Mac OS X preference module that let you display on your desktop all kind of informations.



	
Historically, it could display local files, shell commands, or images from the internet, dynamically. It opens a wide range of usage from simple log file monitoring to web cam on your desktop.



	
Now I restarted this project from scratch, it is more structured, modular, compatible with leopard, etc...



	
There is also a Twitter feed you may want to follow @geektool.



	
Please read the FAQ and HelpDeveloper before sending email or report bugs



	
Source code



	
The source code is not yet available, that's because I did not decided yet how I will distribute it. It may become donationware, it may become opensource too, I don't know exactly.



	
Nightly build



	
Latest nightly build is available at this address : http://update.tynsoe.org/geektool3/Beta/GeekTool-latest.zip



	
New nightly will be announced on Twitter, I don't see an easier way for now



	
Icon



	
Yes, Geektool needs a shiny new icon... If you feel inspired, send me your suggestions at geektool at tynsoe.org



	
At this time, I received two proposals :



	
 and 



Feel free to discuss it in the forum

	
Backing up



	
Geektool settings are stored in ~/Library/Preferences/



	
Each type of Geeklet has its own preference file to avoid the risk of messing the whole configuration if a Geeklet fail in some way.



	
Basically, copy ~/Library/Preferences/org.tynsoe.geek* somewhere and you should be safe



	
(Or restore those file from the TimeMachine backup you must have)



	
Usage Samples