gtg-contributors team mailing list archive

[meg ford <meg387@xxxxxxxxx>]

I did get liblarch through git, but I had to install liblarch_gtk
separately. Why is that?

On Sun, Mar 25, 2012 at 12:42 PM, Lionel Dricot <ploum@xxxxxxxxx> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm very surprized because if you launch gtg without liblarch, it
> should give you the command line to type to get liblarch. (git branch)
>
>
>
> Le 25/03/12 19:25, Bertrand Rousseau a écrit :
> > I guess this should be reported. Izidor, Ploum, should this be
> > reported in github[1]?
> >
> > [1] https://github.com/liblarch/liblarch
> >
> > On Sun, Mar 25, 2012 at 8:03 AM, meg ford <meg387@xxxxxxxxx>
> > wrote:
> >> It's a little hard to get trunk up and running in Fedora, since
> >> there are no liblarch_gtk.rmp packages, and the readme doesn't
> >> explain that you need to use python setup.py install to install
> >> the liblarch dependencies. Maybe someone could document how to
> >> add the dependencies for Fedora at some point.
> >>
> >>
> >> On Sat, Mar 24, 2012 at 9:50 AM, meg ford <meg387@xxxxxxxxx>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I fixed this, or at least it runs tests now.
> >>>
> >>> Meg
> >>>
> >>>
> >>> On Fri, Mar 23, 2012 at 7:35 PM, meg ford <meg387@xxxxxxxxx>
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I would like to ask a question (I also already asked Izidor
> >>>> this via email, but in case this is a better place to ask,
> >>>> here it is:
> >>>>
> >>>> I want to go ahead and fix a bug. I have the bzr for gtg, and
> >>>> the tarball for liblarch on the same level in my directory as
> >>>> gtg. But I get an error when I try to:[meg@meg trunk]$ ./gtg
> >>>> Traceback (most recent call last): File "./gtg", line 103, in
> >>>> <module> import GTG.gtg File
> >>>> "/home/meg/gtg/trunk/GTG/gtg.py", line 58, in <module> from
> >>>> GTG.gtk.manager    import Manager File
> >>>> "/home/meg/gtg/trunk/GTG/gtk/manager.py", line 34, in
> >>>> <module> from GTG.gtk.browser.browser import TaskBrowser File
> >>>> "/home/meg/gtg/trunk/GTG/gtk/browser/browser.py", line 44,
> >>>> in <module> from GTG.gtk.browser.treeview_factory import
> >>>> TreeviewFactory File
> >>>> "/home/meg/gtg/trunk/GTG/gtk/browser/treeview_factory.py",
> >>>> line 30, in <module> from liblarch_gtk
> >>>> import TreeView ImportError: No module named liblarch_gtk
> >>>>
> >>>>
> >>>> I have liblarch on the same level in my directory as gtg. How
> >>>> do I resolve the error?
> >>>>
> >>>> Thanks, Meg
> >>>>
> >>>>
> >>>> 2012/3/23 Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>
> >>>>>
> >>>>> I'd like to make a comment about this thread. It is
> >>>>> actually more about the redesign effort in general than the
> >>>>> actual mockup proposal. I'm changing the subject as such,
> >>>>> so that we can split the discussions.
> >>>>>
> >>>>> (Btw, Alex, I really like the mockups you proposed. They're
> >>>>> great, and they make me want to use this GTG. ;-) )
> >>>>>
> >>>>> I think Meg has raised a very important point, and I'd like
> >>>>> to insist on it to make sure that it doesn't get unnoticed:
> >>>>> mockuping is awesome, but we *must* also work with other
> >>>>> tools like use cases, wireframes, etc. (I think Meg also
> >>>>> mentioned flowcharts, with which I'm not familiar with).
> >>>>> Moreover, as discussed on the IRC channel, since we
> >>>>> contemplate the idea of redesigning and thus partly
> >>>>> redefining GTG, we *must* also try to define clearly what
> >>>>> we think GTG is, what are the goals of the project, etc.
> >>>>>
> >>>>> Indeed, historically, GTG has been built without those, and
> >>>>> at this point of its life, I think it has become apparent
> >>>>> that this gap should be filled. Indeed, we often speak
> >>>>> about GTG's features or UI elements, but we increasingly
> >>>>> lack the "big picture". That was fine when GTG was young
> >>>>> and targeted a limited number of features. But now GTG is
> >>>>> more than three year old (can you believe that??), and it
> >>>>> has become very ambitious (go see our wishlist if you don't
> >>>>> believe me!).
> >>>>>
> >>>>> An application's reason to be is to solve issues, primary
> >>>>> needs. Stuffs like "I need to know what I'm supposed to do
> >>>>> when I have free time at home"... (while "I'd like to
> >>>>> define 3 different tags to sort my tasks" is a *derived*
> >>>>> need.)
> >>>>>
> >>>>> I have the feeling that we very often talk about derived
> >>>>> needs. I'm growing kind of sure that we sometimes cannot
> >>>>> even say if the proposed solution for that derived need
> >>>>> will actual satisfy correctly a primary need at all, that
> >>>>> we looked at the problem with "in the grand schemes of
> >>>>> things", and not too focused on this particular issue.
> >>>>>
> >>>>> We should thus take the time to define correctly what are
> >>>>> the primary *needs* we want GTG to provide a solution for,
> >>>>> so that we can safely derive the solutions we will put into
> >>>>> place to satisfy those needs, and still be able to trace
> >>>>> its rationale back to the "big picture".
> >>>>>
> >>>>> Well, that's exactly what goal definitions are useful for.
> >>>>> So that's where we should start. I actually offered myself
> >>>>> to bootstrap this by writing down some kind of 'gtg
> >>>>> manifesto'. I will try to do so in the next coming days,
> >>>>> and post a draft on the wiki. [note: By the time I'm
> >>>>> writing this, Lionel has actually started the work (kudos,
> >>>>> ploum!): https://live.gnome.org/gtg/manifesto I'll join and
> >>>>> contribute asap]
> >>>>>
> >>>>> But that's not all: to make sure we build up good
> >>>>> solutions, the process consists in decomposing the big
> >>>>> problems in more specific issues for which we can design
> >>>>> solutions. However to make sure a solution is good, one
> >>>>> needs tools that  provide sufficient analytical power to
> >>>>> evaluate the fitness of a particular situation. That's
> >>>>> exactly what tools like use cases, etc. are made for! They
> >>>>> provide each a certain view on an issue, and allow to
> >>>>> analyze the outcome of a solution in a (more) objective
> >>>>> manner. They allow to construct objective advice on which
> >>>>> solution is the best.
> >>>>>
> >>>>> So that's why we should also start to contribute on that
> >>>>> part. I definitely think goal definitions and better
> >>>>> analytical tools should be cornerstones of the ongoing
> >>>>> redesign effort.
> >>>>>
> >>>>> I will personally try to find some time to contribute to
> >>>>> those. I also really hope that we will get a GSoC that will
> >>>>> also help us to contribute useful resources in this domain.
> >>>>> I would also really like anybody interested in GTG's design
> >>>>> and redesign to also consider to contribute with this.
> >>>>>
> >>>>> Ok, that's it! Thanks for reading me all the way to here,
> >>>>> it's been (again) longer than expected! (please bear with
> >>>>> me)
> >>>>>
> >>>>> Bertrand
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> This the kind of thing that actually allows one to decide
> >>>>> if buttons should be placed on the right or the left, if
> >>>>> tasks should be ordered or not, if there should any
> >>>>> difference between plugins or backends, etc. 2012/3/23
> >>>>> Izidor Matušov <izidor.matusov@xxxxxxxxx>:
> >>>>>> Hi Alex and other GTG contributors,
> >>>>>>
> >>>>>> sorry for the late answer, many things are going on and I
> >>>>>> am piled in my e-mail. I love your mockups and I find it
> >>>>>> awesome. In this e-mail I would to raise some details
> >>>>>> which weren't discussed so far. Please, don't take it as
> >>>>>> nitpicking :-)
> >>>>>>
> >>>>>>> *General Layout:*
> >>>>>>>
> >>>>>>> The Layout contains the Primary Toolbar (1), which
> >>>>>>> holds the 'new task' button and a View Switcher. I dont
> >>>>>>> know if the Checkmark Selector (on the right side) is
> >>>>>>> really necessary, the space could also be used for
> >>>>>>> buttons which allow to toggle between different views.
> >>>>>>> On the left you can see the Tag-Sidebar (2) and on the
> >>>>>>> bottom you can find the plugin toolbar (3), which holds
> >>>>>>> all additional elements required by plugins. The plugin
> >>>>>>> toolbar is only visible, if there are any plugins
> >>>>>>> enabled.
> >>>>>>
> >>>>>>
> >>>>>> I think view switcher should have these options: * active
> >>>>>> tasks - tasks that are shown in the current GTG window *
> >>>>>> next action / Work View - tasks that: * don't have any
> >>>>>> active subtasks * don't have start date or have start
> >>>>>> date in past * are not marked to be due Someday * don't
> >>>>>> have assigned any tag which is hidden in workview
> >>>>>>
> >>>>>> * in other words, tasks that I can work on at the moment
> >>>>>> * Tasks without tags -> something like Inbox * closed
> >>>>>> tasks - done + dismissed tasks * all tasks -- all tasks
> >>>>>> that are stored in GTG
> >>>>>>
> >>>>>> Those modes would satisfy the needs of this bug
> >>>>>> https://bugs.launchpad.net/gtg/+bug/630477 - make user
> >>>>>> aware about "special modes"
> >>>>>>
> >>>>>> ***************************
> >>>>>>
> >>>>>> A new concept in the latest GTG is backends. You can
> >>>>>> synchronize your tasks with services like Google Tasks,
> >>>>>> Remember the Milk. Those services requires authentication
> >>>>>> in the browser (most of them).  The current workflow is:
> >>>>>>
> >>>>>> - Open Edit->Backends and add new backends - Click on
> >>>>>> Allow syncing - In the task browser gtk.InfoBar is shown
> >>>>>> (see 01.png) and furter action is required like entring
> >>>>>> pincode (see 02.png)
> >>>>>>
> >>>>>> The process is quite cumbersome. Maybe authentication
> >>>>>> should be part of add backend dialog and not clutter
> >>>>>> browser interface.
> >>>>>>
> >>>>>> Nevertheless we need some form of communication from
> >>>>>> backends to user, mostly about errors: * a service
> >>>>>> require new authentication like revoked permission *
> >>>>>> backend was disabled because of lack of network * backend
> >>>>>> was disabled because other programs does not response,
> >>>>>> e.g. Gnote see
> >>>>>> https://bugs.launchpad.net/gtg/+bug/932877
> >>>>>>
> >>>>>> Is it okay to show gtk.Infobar with the error message and
> >>>>>> a single button which dismiss the InfoBar and open that
> >>>>>> backend's settings? Should be those messages stackable
> >>>>>> (in case of failing multiple backends show all warning
> >>>>>> at once) or show just single one, dimiss it and show
> >>>>>> another one? What is GNOME policy for that? Could you
> >>>>>> create a mockup for that?
> >>>>>>
> >>>>>>> *Sidebar:*
> >>>>>>>
> >>>>>>> I think the Sidebar should be enabled by default, since
> >>>>>>> it's a very powerful feature and there is enough
> >>>>>>> horizontal space to display it. I also increased the
> >>>>>>> size of the items in the sidebar to 28px, which is the
> >>>>>>> recomended minimum size of touchable buttons stated by
> >>>>>>> the Noika Developers Guide. Google also uses this size
> >>>>>>> for sidebar entrys in the new Google Mail layout.
> >>>>>>
> >>>>>>
> >>>>>> In the current GTG, the sidebar is hidden by default to
> >>>>>> give look of very simple UI on startup. It is advised to
> >>>>>> turn it off in the initial tasks tutorial. However, I
> >>>>>> haven't seen anybody to use GTG without it because it is
> >>>>>> very powerful also for newbies.
> >>>>>>
> >>>>>> I vote for making sidebar the default par of UI and
> >>>>>> getting rid of option to turn it off.
> >>>>>>
> >>>>>> *********************
> >>>>>>
> >>>>>> GTG allows you to stack tags. You can have hierarchical
> >>>>>> tags:
> >>>>>>
> >>>>>> @Work - @project1 - @project2 @School - @courseA -
> >>>>>> @courseB
> >>>>>>
> >>>>>> Could you create a mockup of such an advance usage?
> >>>>>>
> >>>>>> ********************
> >>>>>>
> >>>>>> Get rid of "All tasks" and "Task without tags" (they
> >>>>>> should be shown in special view). In the sidebar should
> >>>>>> be shown only tags and smart tags a.k.a saved searches
> >>>>>> (read later).
> >>>>>>
> >>>>>> There was a request for allowing to select multiple tags
> >>>>>> and creating a context, e.g. I select @call and @work to
> >>>>>> see all work-releated calls. If no tags are selected, all
> >>>>>> tasks are shown.
> >>>>>>
> >>>>>> The question is if we want to implement intersection or
> >>>>>> union of tags. After having a jabber chat with Ploum, we
> >>>>>> figured out it is hard to choose which way to go. In each
> >>>>>> way, we would like to have multiple selection in UI.
> >>>>>>
> >>>>>>
> >>>>>> *********************
> >>>>>>
> >>>>>> I can't see the icon assigned to @work. Is it smaller
> >>>>>> when it is shown next to the text title?
> >>>>>>
> >>>>>> *********************
> >>>>>>
> >>>>>> I love your mockup of tag editor! There is a request to
> >>>>>> create permanent tags (shown although no task is assigned
> >>>>>> to it). Having another checkbox wouldn't be a problem.
> >>>>>>
> >>>>>>> ** * Tasks:*
> >>>>>>>
> >>>>>>> I'm struggling with the design of the tasks since i
> >>>>>>> began working on the GUI, so please don't consider this
> >>>>>>> anything but far from completed.
> >>>>>>>
> >>>>>>> Although iOS nor Android or any other touch-optimized
> >>>>>>> OS seem to use tree views, i think we should stick to
> >>>>>>> it, since they are great for visualizing hierarchy. I'm
> >>>>>>> not completely satisfied with the design of the tasks,
> >>>>>>> so if you have any ideas how to improve the visual
> >>>>>>> design of the tasks, please feel free to tell me.
> >>>>>>
> >>>>>>
> >>>>>> Ploum asked:
> >>>>>>> Now, playing devil's advocate, I want to point out that
> >>>>>>> each task take a lot more room than with the current
> >>>>>>> GTG version. It means that you can display only half or
> >>>>>>> the third number of tasks.
> >>>>>>>
> >>>>>>> Is this something acceptable or should we have a "thin
> >>>>>>> mode"?
> >>>>>>
> >>>>>> In my opinion, it would be feature of GTG. I have the GTG
> >>>>>> browser window of a normal size for my laptop (920x591)
> >>>>>> and I can put there about 20 tasks. (See 04.png) When I
> >>>>>> do my daily planing, I check several times how my
> >>>>>> schedule looks like. Unconsciously I end up with the full
> >>>>>> window of tasks because adding one more task is just
> >>>>>> about few pixels. When I constrain it consciously, it
> >>>>>> feels like I underestimate myself: Look fool, you have
> >>>>>> only the half window to do today, you have enough time to
> >>>>>> check news again...
> >>>>>>
> >>>>>> GTG could display about 6-8 tasks in the same window.
> >>>>>> Given "rule 7 +-2", humans (at least I) have problems
> >>>>>> with dealing many items at the same time. We would force
> >>>>>> the user to categorize tasks into smaller chunks (or to
> >>>>>> store less tasks). I personally believe that GTG's (and
> >>>>>> other ToDO lists) core feature is filtering: show me only
> >>>>>> the relevant tasks I can work on given the context.
> >>>>>>
> >>>>>> *********************************
> >>>>>>
> >>>>>> There was proposed feature to group tasks by due date:
> >>>>>> https://bugs.launchpad.net/gtg/+bug/340022
> >>>>>>
> >>>>>> IMHO it is not quite possible to do with the list of
> >>>>>> hierarchical subtasks: I could have a task with one
> >>>>>> subtask due today and another subtask due tomorrow.
> >>>>>> Should I put the whole subtask to today chunk or
> >>>>>> tomorrow chunk? Should I split those subtasks although
> >>>>>> they belong to the single task?
> >>>>>>
> >>>>>>> *Quick-Add/Search Bar:*
> >>>>>>>
> >>>>>>> The Gnome HIGs have very strict requirements regarding
> >>>>>>> the search (see
> >>>>>>> https://live.gnome.org/Design/HIG/Search. To quote the
> >>>>>>> HIG:
> >>>>>>>
> >>>>>>> "Typically, the search entry field should be located
> >>>>>>> out of view, at the top of the list or grid content
> >>>>>>> area. The search field can be accessed in three ways: -
> >>>>>>> Scrolling the content up when it is at its apparent
> >>>>>>> upper limit. - Using the standard search keyboard
> >>>>>>> shortcuts - Ctrl+F or Ctrl+S - Typing when a text input
> >>>>>>> field is not focused - this text should be
> >>>>>>> automatically entered into the search field"
> >>>>>>>
> >>>>>>> If we follow the Guidelines, we have to abandon the
> >>>>>>> search functionality from the quick-add toolbar. The
> >>>>>>> current idea is to get completly rid of the quick-entry
> >>>>>>> text input filed and show the user a empty task, which
> >>>>>>> can be filled out, instead.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> In GTG 0.2.9 there was added concept of searches. You can
> >>>>>> search by entering a query in a simple query language.
> >>>>>> Look at the comment there:
> >>>>>>
> >>>>>>
> >>>>>>
> http://bazaar.launchpad.net/~gtg/gtg/trunk/view/head:/GTG/core/search.py
> >>>>>>
> >>>>>>
> >>>>>>
> Joao worked on Search dialog where you could set it up from UI. In the
> >>>>>> end of summer we came with the idea of "Awesome bar"
> >>>>>> where you just write your query. As you know, we are
> >>>>>> going to get rid of "Awesome bar" and therefore the
> >>>>>> question is if we would like to have a complicated dialog
> >>>>>> with many options or users enter just a query. Query
> >>>>>> might be more geeky solution but on the other side: - it
> >>>>>> would provide cleaner interface - most user would use it
> >>>>>> only to find tasks with certain words or tags - only a
> >>>>>> fraction of users would need special operators
> >>>>>>
> >>>>>> I personally see the clean, Google's searchbar interface
> >>>>>> :-) I don't know about any GNOME application which would
> >>>>>> provide advanced search feature besides e-mail clients
> >>>>>> like Evolution or Thunderbird (their interface is very
> >>>>>> clumsy :-(
> >>>>>>
> >>>>>> We allowed to create smart tags a.k.a. saved searches.
> >>>>>> You write complex search queries like '@gtg !before
> >>>>>> 2011-05-01 !not "feature request"', it would be saved
> >>>>>> into sidebar and you can give a name to it, color, etc.
> >>>>>> It is like a normal tag but you can specify a query for
> >>>>>> it.
> >>>>>>
> >>>>>> One of ideas was to automatically save every search. User
> >>>>>> can rename a search, update query or delete it. We could
> >>>>>> purge those searches automatically (remember just last 5;
> >>>>>> forget them after restart; - of course, you could pin
> >>>>>> them to make them permanent like it is in tomboy's
> >>>>>> notification area) or let user to delete them manually.
> >>>>>>
> >>>>>> Searches are quite new concept.
> >>>>>>
> >>>>>> I would propose Search dialog to be:
> >>>>>>
> >>>>>> ----------------------------------------------- |
> >>>>>> ____________________________        | | Query:
> >>>>>> |____________________________| help  | |
> >>>>>> _________________   | | ☑ save it as smart tag
> >>>>>> |_________________|  | |
> >>>>>> --------    | |                                | Search |
> >>>>>> | |                                 --------    |
> >>>>>> -----------------------------------------------
> >>>>>>
> >>>>>> Where help would be a link/would open documentation of
> >>>>>> search query.
> >>>>>>
> >>>>>> If user choose to save the tag, it would be shown in the
> >>>>>> sidebar in the same way as in the current GTG (see
> >>>>>> 03.png)
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> * Opening & editing tasks:*
> >>>>>>>
> >>>>>>> I haven't done a mockup of how tasks should be edited
> >>>>>>> yet, but my idea was to get rid of the
> >>>>>>> 'one-window-per-task' appraoch wich works great on the
> >>>>>>> desktop, but could cause some problems on small
> >>>>>>> touchscreen devices. I think it would be nice, if GTG
> >>>>>>> would handle tasks, like other Gnome 3 core apps handle
> >>>>>>> files (See
> >>>>>>>
> >>>>>>>
> >>>>>>>
> https://live.gnome.org/Design/HIG?action=AttachFile&do=get&target=index2.png
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> <
> https://live.gnome.org/Design/HIG?action=AttachFile&do=get&target=index2.png
> >).
> >>>>>>
> >>>>>>
> >>>>>> I agree that editing only one task at the time could be
> >>>>>> better.
> >>>>>>
> >>>>>> I think the overall layout of the current editor embedded
> >>>>>> in the main window would be okay. In the top toolbar
> >>>>>> there could be buttons:
> >>>>>>
> >>>>>> - back (show previous open task or task browser) - go to
> >>>>>> the parent task -------------------- - mark as done -
> >>>>>> mark as dismissed - delete ---------------- - insert tag
> >>>>>> - insert subtask ------------------ - <plugin buttons
> >>>>>> like Hamster - start tracking this task>
> >>>>>>
> >>>>>> On the bottom toolbar: - start date widget - due date
> >>>>>> widget - text information: how many days are left
> >>>>>>
> >>>>>> In the context many would be those options: - spell
> >>>>>> checking - open link ( if clicked on link ) - basic rich
> >>>>>> text operations: make text bold/italic - insert tag -
> >>>>>> insert subtask
> >>>>>>
> >>>>>>
> >>>>>> ****************************************************
> >>>>>>
> >>>>>> While writing this e-mail, I got your other e-mail. Most
> >>>>>> questions are answered above.
> >>>>>>
> >>>>>>
> >>>>>> - should we stick with the 'empty-task-approach?
> >>>>>>
> >>>>>> I think that the empty-task at the top should be just one
> >>>>>> line Entry widget. If you have a complex widget like in
> >>>>>> your last mockup, it doesn't make any sense. You can't
> >>>>>> fill it just from keyboard easily and you have to use
> >>>>>> mouse or <tab> button. It means you degrade to a form on
> >>>>>> very small place. The main purpose of QuickAdd toolbar is
> >>>>>> to quickly and easily add many task (optimally with their
> >>>>>> structure) from keyboard.
> >>>>>>
> >>>>>>
> >>>>>> - what do you think of the task design? (3)
> >>>>>>
> >>>>>> I prefer the style from this mockup:
> >>>>>> http://i.imgur.com/X3zB5.png
> >>>>>>
> >>>>>> I love the title idea form that mockup! The title could
> >>>>>> help users to understand concepts of filters (you seen
> >>>>>> text description of what you see).
> >>>>>>
> >>>>>> ********************************************************
> >>>>>>
> >>>>>> That's pretty much it. Looking forward to your answers,
> >>>>>>
> >>>>>> Izidor
> >>>>>>
> >>>>>> P.S: What software do you use to create those mockups?
> >>>>>> Gimp, Inkscape with some plugins or something else? I
> >>>>>> would like to create some my own modification instead of
> >>>>>> ASCII art...
> >>>>>>
> >>>>>> _______________________________________________ Mailing
> >>>>>> list: https://launchpad.net/~gtg-contributors Post to
> >>>>>> : gtg-contributors@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >>>>>> https://launchpad.net/~gtg-contributors More help   :
> >>>>>> https://help.launchpad.net/ListHelp
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -- Bertrand Rousseau
> >>>>>
> >>>>> _______________________________________________ Mailing
> >>>>> list: https://launchpad.net/~gtg-contributors Post to     :
> >>>>> gtg-contributors@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >>>>> https://launchpad.net/~gtg-contributors More help   :
> >>>>> https://help.launchpad.net/ListHelp
> >>>>
> >>>>
> >>>
> >>
> >
> >
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9vWRoACgkQMvYGdShAWjixswCfank6Zx1Rd5uYIBVWf/+5srjv
> /ecAn1y8ZUA0CklkIVWDlVrw4bxxdutY
> =pmeV
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-contributors
> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-contributors
> More help   : https://help.launchpad.net/ListHelp
>