-----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 <[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 >>>> >>>> >>> >> > > > -----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----- _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
