gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

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