gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

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



-- 
Bertrand Rousseau