From: Serge N. <Ser...@fr...> - 2010-11-22 22:40:50
|
Benny Malengier a écrit : > > > 2010/11/22 Serge Noiraud <Ser...@fr... > <mailto:Ser...@fr...>> > > Benny Malengier a écrit : > > > > 2010/11/22 Doug Blank <dou...@gm... > <mailto:dou...@gm...> <mailto:dou...@gm... > <mailto:dou...@gm...>>> > > > Thanks for all of the feedback! > > It seems all of the arguments so far have been about the > UI, which is > fine. That suggests that we can get rid of the two > different ways of > functioning and collapse that down to just one (the way > that sidebar > works, perhaps with some niceties added). That would get > rid of having > to explain differences. > > The problem remaining, then, is how to make a consistent UI > that could > use either a simple, topbar filter, or something more (and even > suggest to users that there is something more powerful > available). > > Some ideas: > > 1) Have a simplified topbar available for single entry, > simple filters > (either a single column, or a single custom filter). > 2) This might require that every field have associated with > it a > filter (so that date columns would be searched by the date > logic, > "male" would not match "female", note would search the > entire text, > etc) > 3) More complex filters could be available by having a "+" > button in > the topbar, which would bring up a dialog (not sidebar). > That would > prevent real estate from being eaten up. The topbar would > become a > button indicating that a more complex filter is in effect. > Clicking it > would bring up the dialog (which used to be the sidebar > filter). > 4) This would integrate the topbar/sidebar as the topbar > would be a > simplified version of the full dialog, and only shown when > the dialog > isn't. > 5) This also removes some of the complexity by just making > the sidebar > a dialog, which is either opened or closed, and makes it so > that its > showing is independent of the gramplet pane. (As an aside, > the full > filter dialog could be dockable in the gramplet pane, which > would give > nearly the current appearance of the sidebar filter). > > Does anyone see any issue with that type of strategy? > > > It is hard to envisage what you mean. > I suppose the gramplet pane can be closed also. > > Technically I know very good how topbar/sidebar relates to the > view as I rewrote that with Nick for 3.2. The changes you want > to do go deep in the core code and are not that simple. > What is the global strategy? > > 1. We still have the problem in trunk that Geoview is broken > with panes. That needs a solution, meaning several of us will > have to try and fix that. Serge thinks it is a Gtk bug... > > NO. it's not a gtk but a gtk-webkit bug or a not implemented > functionality for webkit in a paned window. > > I'm interested too in this new filter as I incorporated navigation > and filters into geoview. > I'm actually trying to break geoview in several modules and classes. > The navigation an filters will be some of them. > > > Yes, Geoview must be broken up in smaller pieces. > Can you do that work in a new branch which we merge back in later. Or > do you expect this to be finished in 1 or 2 weeks? It will never be finished in two weeks. I have a lot of work to do at home and only a few for genealogy ( and gramps ) at this moment. This is the beginning as I want to suppress webkit and gtkmozembed and do all the work in python. 1 - It will be easier to manage. 2 - We could interact with the map as we want. 3 - We'll have a local map 4 - Avoid an internet connexion except when we want to update the local map. 5 - Reduce gramps dependencies 5 - Many, many work ... Perhaps the best could be to create a GEPS for this new geoview. I don't know how to do this and how to manage it. > > Benny |