Hi, I fixed this, or at least it runs tests now.
Meg On Fri, Mar 23, 2012 at 7:35 PM, meg ford <[email protected]> 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 <[email protected]> > >> 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 <[email protected]>: >> > 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 : [email protected] >> > Unsubscribe : https://launchpad.net/~gtg-contributors >> > More help : https://help.launchpad.net/ListHelp >> > >> >> >> >> -- >> Bertrand Rousseau >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~gtg-contributors >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~gtg-contributors >> More help : https://help.launchpad.net/ListHelp >> > >
_______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
