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 <[email protected]> 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 <[email protected]> wrote: >> >> 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 >>> >>> >> > -- 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
