gtg-contributors team mailing list archive

[meg ford <meg387@xxxxxxxxx>]

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
>>
>
>