gtg-contributors team mailing list archive

[meg ford <meg387@xxxxxxxxx>]

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
>