gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 25/03/12 19:49, meg ford a écrit :
> I did get liblarch through git, but I had to install liblarch_gtk 
> separately. Why is that?

If you use trunk version of GTG, you should also use trunk version of
liblarch (which contains liblarch_gtk).

Forget about packages and setup.py or anything. Just launch GTG trunk
from within the folder with ./gtg and but the liblarch folder on the
same level.


(it looks like liblarch is packaged in Fedora but without
liblarch_gtk, that may be the root of your problem)


> On Sun, Mar 25, 2012 at 12:42 PM, Lionel Dricot <ploum@xxxxxxxxx 
> <mailto:ploum@xxxxxxxxx>> wrote:
> 
> 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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
>
> 
<http://bazaar.launchpad.net/%7Egtg/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>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
> <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
> <https://launchpad.net/%7Egtg-contributors> Post to
>>>>>>> : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> <mailto:gtg-contributors@xxxxxxxxxxxxxxxxxxx> Unsubscribe :
>>>>>>> https://launchpad.net/~gtg-contributors
> <https://launchpad.net/%7Egtg-contributors> More help   :
>>>>>>> https://help.launchpad.net/ListHelp
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- Bertrand Rousseau
>>>>>> 
>>>>>> _______________________________________________ Mailing 
>>>>>> list: https://launchpad.net/~gtg-contributors
> <https://launchpad.net/%7Egtg-contributors> Post to     :
>>>>>> gtg-contributors@xxxxxxxxxxxxxxxxxxx
> <mailto:gtg-contributors@xxxxxxxxxxxxxxxxxxx> Unsubscribe :
>>>>>> https://launchpad.net/~gtg-contributors
> <https://launchpad.net/%7Egtg-contributors> More help   :
>>>>>> https://help.launchpad.net/ListHelp
>>>>> 
>>>>> 
>>>> 
>>> 
> 
> 
> 
> 
> 
> _______________________________________________ Mailing list:
> https://launchpad.net/~gtg-contributors 
> <https://launchpad.net/%7Egtg-contributors> Post to     :
> gtg-contributors@xxxxxxxxxxxxxxxxxxx 
> <mailto:gtg-contributors@xxxxxxxxxxxxxxxxxxx> Unsubscribe :
> https://launchpad.net/~gtg-contributors 
> <https://launchpad.net/%7Egtg-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/

iEYEARECAAYFAk9vXPQACgkQMvYGdShAWjiNvACfUGs/Vb9LGIVxR2n9bmrKGdxQ
SUsAn26nAhyTnX29aM5RQ+J9s56xUexc
=Sa/p
-----END PGP SIGNATURE-----