Yes, I know but if you open the event editor you see directly if it has a source.
If it hasn’t, you can add one.
At that point, you have a lots of clicks: opening an Event, adding the Citation (even if via drag’n’drop from the clipboard, not the minimum of 5 clicks for a "Share"d Citation), commit the changed Event & repeat for the next in the 2 level context menu.
The context menu is a magnificent solution for intermittent use but not practical for running through a dozen people.
One of the Easter Eggs in the CardView is that you can drag’n’drop from the Clipboard to a card.
So, you could drag a Census Event to each sibling without opening each one individually. (Although dropping Events will pop a dialog asking the Role) Or drop a Citation onto cards in the Timeline Events.
So inspecting a Person’s events for Citations the GraphView/CardView way is a quick click in Graph View to focus on a person, a click on the People Navigator category to swap to the Person Card View, look for Citation icons in each event (no clicks unless there’s scrolling), drop a Citation only when necessary, and a click on the Charts navigator to move to the next person. Then repeat.
If the people are immediate family (a parent, sib, spouse or offspring), then use the Relationships category Person CardView. That means just 1 click per person. No need to go back to the Graph View until you exhaust a branch.
1 Like
Chris and I have been discussing something very similar recently.
The Card view is now actually composed of a group of related views. I could also do the same with the Combined view. We now need a good way of navigating between these views.
Changing to a new view based navigation would seem to be the way forward. We would maintain a stack of views together with their status. Any view could call any other view or itself with a different status (a different active object for example).
With this framework it would be possible for the graph view to reach the Combined Events view directly. Clicking the “back” button would return to the calling graph view.
I can see that this may be useful in other views. For example, we could call the appropriate Card from a list view. This would make viewing objects a flat experience rather than possibly having to open multiple editor windows.
When populating a context menu we would have to list all relevant views, and maybe suggest a default option.
I’m not sure how best to integrate our legacy navigation at the moment. Perhaps we don’t even need it?
2 Likes
I really like the CardView and the Combined view mode. They are nimble & responsive.
But for some tasks they feel like trying walk on quicksand. You can lose your orientation too easily and you cannot grab objects easily for drag’n’drop.
When working a dataset systematically, the existing lists are more stable & predictable. Also, many of the typical task can be done without touching a mouse. The new view mode GUIs under development are highly mouse dependent.
The hybrid seems to be ideal. And, with the Plugin Manager people with strong feelings in one direction can HIDE built-in & add-on plugins to completely customize the Gramps GUI.
For instance, Dave suggested hiding the 2 Navigator modes that I do not use. This simplifies my interface and allows that sidebar to be slimmer.
Hi Serge, this one is interesting, no one has reported an issue loading the plugin before. Does same thing happen with more recent copy?
I increasingly think there is value in both having a global navigation history across objects, but also being able to apply a linear history in the context of the list views. That is how I am manging things now and it seems to fit well with your navigation group concept.
I really like the idea of being able to populate the context menu with a list of available places across all the views that you can navigate too.
I think the default though, if just clicking a link or link sensitive object, should be to stay within the navigation group.
Impossible to do. But we can add a contextual menu like the following:
Hello,
Small problem: I don’t have the “Events” contextual menu when right-clicking on the active individual in “Graphview” ???
It looks like Serge liked your idea and is running a personal experiment. (Nice job identifying a good workflow improvement!) He has gifted the community with many other powerful features. If it works to his satisfaction, he will probably release an update to the Graph View addon.
Ivan has other things on his plate right now and would be glad to see someone adding things to Graph View.
2 Likes
Yes. I’d like the navigation to contain the history of both objects and views, instead of just objects as we have currently.
I’d also like to have the ability to jump from one view to another and be able to return to the previous view using the “Back” button. For example, consider the person list view with a filter. It would be useful to be able to click on a row and visit a details view before clicking “Back” and returning to the previous list view. In this way we could use detailed views in a similar way that we currently use the editors. This would eliminate the common complaint of multiple nested open editors when viewing information.
Perhaps we could then give the user the option of changing the enter or double-click behaviour in list views from “Edit” to “View”.
Yes! Configuration of Links clicks (being Edit or Navigate) would be lovely. (Logitech had a nice graphical interface for remapping Mouse buttons a couple decades ago.)
Chris has designed CardView with a 3-button mouse in mind.
In the Last Changed gramplet:
- Left-click=Navigate to Associated CardView
- Right-click=Edit object
- Center-click=Navigate to Gramps default mode for Category
In the CardView modes:
- Left-click=Navigate to Associated CardView
- Right-click=Context menu
- Center-click in the CardView offers Configuration-on-the-fly
He’s got some modifier clicks in there too. But my heart’s palpitating too badly to describe those after experimenting.
+1
ERREUR : échec à la lecture de l'enregistrement du greffon card_view.gpr.py
Traceback (most recent call last):
File "gramps/gen/plug/_pluginreg.py", line 1199, in scan_dir
assert pdata.id not in self.__id_to_pdata
AssertionError
2022-06-01 09:31:40.495: ERROR: grampsapp.py: line 174: Unhandled exception
Traceback (most recent call last):
File "gramps/gui/grampsgui.py", line 794, in do_activate
Gramps(self.argparser, self)
File "gramps/gui/grampsgui.py", line 647, in __init__
self._vm.post_init_interface()
File "gramps/gui/viewmanager.py", line 551, in post_init_interface
self.__open_activate(None, None)
File "gramps/gui/viewmanager.py", line 968, in __open_activate
self.db_loader.read_file(filename)
File "gramps/gui/dbloader.py", line 180, in read_file
db = make_database(dbid)
File "gramps/gen/db/utils.py", line 60, in make_database
pdata = pmgr.get_plugin(plugin_id)
File "gramps/gen/plug/_manager.py", line 400, in get_plugin
return self.__pgr.get_plugin(id)
File "gramps/gen/plug/_pluginreg.py", line 1272, in get_plugin
assert(len(self.__id_to_pdata) == len(self.__plugindata))
AssertionError
by adding, print(pdata.id, filename),
on gramps/gen/plug/_pluginreg.py", line 1199,
we can suppose a naming issue (class, id, etc.)
on personcardview:
personcardview card_view.gpr.py
personcardview card_view.gpr.py
ERREUR : échec à la lecture de l'enregistrement du greffon card_view.gpr.py
Traceback (most recent call last):
File "gramps/gen/plug/_pluginreg.py", line 1200, in scan_dir
assert pdata.id not in self.__id_to_pdata
AssertionError
field_child field_child.gpr.py
status_todo status_todo.gpr.py
field_marriage_age field_marriage_age.gpr.py
LastChanged last_changed.gpr.py
status_person status_person.gpr.py
field_relationship field_relationship.gpr.py
template_minimal template_minimal.gpr.py
field_duration field_duration.gpr.py
field_progenitors field_progenitors.gpr.py
field_occupations field_occupations.gpr.py
tagview tagview.gpr.py
Ah, so I copied and pasted and edited the category to add it to Relationships but the id field likely needs to be unique.
It is odd that I don’t get an error like both of you though. I wonder why that is.
I assume if you edit the second id and change to relationshipcardview then all is well?
I do not think having it under both People and Relationships is a good idea. Other than entering the card views through the Person card under Relationships, all other navigation from within the other card views back to the person card utilizes the option under People.
Personally, I commented out the entry under Relationships in card_view.gpr.py .
I also added “… Card” for each of the views. I wanted a better distinction between views in the drop-down list.
Still exploring the views.
I found the problem for cardview:
The personcardview is registered twice. I commented out the first registered lines and it works.
# register(
# VIEW,
# id="personcardview",
# name=_("Person"),
# description=_("A browseable Person card view."),
# version=VERSION,
# gramps_target_version=GRAMPS_TARGET_VERSION,
# status=STABLE,
# fname="card_view_person.py",
# authors=AUTHORS,
# authors_email=AUTHORS_EMAIL,
# category=("People", _("People")),
# viewclass="PersonCardView",
# stock_icon="gramps-relation-linked",
# order=END,
# )
register(
VIEW,
id="personcardview",
name=_("Person"),
description=_("A browseable Person card view."),
version=VERSION,
2 Likes
Via configuration, I was able to turn off the Parents & Siblings column & remove the relatives’ events from the Person CardView mode in the People category while simultaneously KEEPING all those features active in the Relationships category. (Nicknamed it the “Selfish” configuration.)
It is less confusing to have such a winnowed down view in the People category. All the other features are the same.
This works well and I would not like to lose that functionality. But maybe the IDs DO need a way to distinguish. The sidebar side in the People category’s Person CardView has corrupted 4 times in the last 2 days.
If users want an additional card view under Relationships, it should have its own Name and ID to avoid confusion. It being a different ‘template’ than the card view under People makes sense. But then how does another card, Event, know which Person card to go to when the person of an event is selected?
1 Like
That is the conundrum, isn’t it?
With the scenario Jean-Claude laid out (in the message that kicked off this digression), it seems like he would want the Graph View to switch to that “selfish” Person CardView mode. Wading through the Citations for JUST one person’s events is far less confusing than all the people in Parent’s family plus the families where they are a spouse. (And that’s without the configuration option to extend the scope of the timeline beyond 1 generation up &down!)
In his case where he is validating, he would probably want the narrow scope with shallow focus.
But when exploring, seeing the interaction with the community allows patterns to be perceived: broader scope with deep focus.
And just think… when the addon becomes a standard addon, how much time will be spent walking other users through this maze of views and configuration.
1 Like
I agree, configuration and explain how to use cardview could be complicated.
What I really like in it, it’s not all its concept but some new ideas in it, like @emyoulation says before, drag a citation into an object without the need to open it or the possibility to have everything about an object opened in a cloned window while working on other objects…
The full Cardview is maybe too much for everyday use. It can be saw as some kind of new concepts POC, but some of these new concepts are very interesting and will have added value for everyday use from my point of view.
My workflow is to use usual relationship view, but sometimes I use combined view to visualize everything about someone, with cardview I could have a new tool in this workflow. It’s probably not a tool I’ll use permanently but which i could used it when it could help me.
Yeah my cut and paste in a hurry likely cause of your issues…