Replacing "Quick Views" with Gramplets

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Replacing "Quick Views" with Gramplets

Brian Matherly
This message is mostly for Doug, but anyone is welcome to chime in...

I was looking at the code that makes up the QuickViews. It it seems to be adding a lot of complexity to the Gramps code base that is redundant with the functionality provided by Gramplets. I am wondering if it would be possible to re-implement the quick views as Gramplets.

Fundamentally, all we need is a way to invoke an undocked Gramplet from the right-click context menu in certain views. Then, we just need to specify which Gramplets can be envoked in which view, depending on whether the Gramplet is person, family, place, or event focused.

The advantages I see are this:

1) We can remove the "Simple" interface which as far as I can tell is only used by quickviews and one Gramplet. I don't really see that the Simple interface adds much value to Gramps.

2) We can remove the TextBuffDoc interface which is a mutated orphan of a previous report format. Many functions are not implemented, and it needlessly inherits from BaseDoc.

3) Any "quick view" that you can get is also available to be docked in the Gramplet view.

Does anyone else think this is a good idea?

Is is possible to pull this off before the 3.1 release?

Thanks,

~Brian

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Replacing "Quick Views" with Gramplets

Douglas S. Blank
> This message is mostly for Doug, but anyone is welcome to chime in...
>
> I was looking at the code that makes up the QuickViews. It it seems to be
> adding a lot of complexity to the Gramps code base that is redundant with
> the functionality provided by Gramplets. I am wondering if it would be
> possible to re-implement the quick views as Gramplets.
>
> Fundamentally, all we need is a way to invoke an undocked Gramplet from
> the right-click context menu in certain views. Then, we just need to
> specify which Gramplets can be envoked in which view, depending on whether
> the Gramplet is person, family, place, or event focused.
>
> The advantages I see are this:
>
> 1) We can remove the "Simple" interface which as far as I can tell is only
> used by quickviews and one Gramplet. I don't really see that the Simple
> interface adds much value to Gramps.
>
> 2) We can remove the TextBuffDoc interface which is a mutated orphan of a
> previous report format. Many functions are not implemented, and it
> needlessly inherits from BaseDoc.
>
> 3) Any "quick view" that you can get is also available to be docked in the
> Gramplet view.

Brian,

I think we can do some consolidating, but maybe in slightly different
ways. I like some aspects of Quick Views. Some further points:

1) Quick Views don't change as the active person changes. Makes it easy to
compare two different ones. Gramplets can't currently be locked to the
current view. (Trying to figure out an elegant way to do that).

2) I really like the Simple interfaces! In fact, I wished that they were
part of the "regular" interface, or better integrated. There are some
really good ideas in there, for beginners and experts.

3) Eventually, I think we need to make the text on the Quick Views be
either copyable or printable. We need to do this for Gramplets, too. The
QVs being based on a doc may help with this. I have some (untested) code
in there to eventually be able to create text rather than the gtk
treeviews, for example.

> Does anyone else think this is a good idea?
>
> Is is possible to pull this off before the 3.1 release?

I'm not sure I'd say that Gramplets are fully mature yet... there are
still some major things I'd like to iron out (options, printing, etc.) I
think that we can simplify, and maybe create a QV-Gramplet hybrid that
takes the best from both.

With school starting up now, I probably won't have a lot of time between
now and March. But I'd be glad to support you with whatever you decide.

I'd recommend letting 3.1 go like it is, and thinking about how to better
integrate these over the next few months.

-Doug

> Thanks,
>
> ~Brian
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Replacing "Quick Views" with Gramplets

Brian Matherly
Doug,

Thanks for your perspective.

> I think we can do some consolidating, but maybe in slightly
> different
> ways. I like some aspects of Quick Views. Some further
> points:
>
> 1) Quick Views don't change as the active person
> changes. Makes it easy to
> compare two different ones. Gramplets can't currently
> be locked to the
> current view. (Trying to figure out an elegant way to do
> that).

If that is the only advantage of Quick Views, then surely we can fix the Gramplets to support it. I'm imagining a small padlock icon in the corner that allows the user to "lock" the gramplet so that it won't respond to callbacks from the uistate.

> 2) I really like the Simple interfaces! In fact, I wished
> that they were
> part of the "regular" interface, or better
> integrated. There are some
> really good ideas in there, for beginners and experts.

I really don't like the Simple interfaces. They are very un-object oriented. They obscure functionality from the user (which is not the same as "hiding complexity"). They are poorly documented. Some function names aren't even verbs (like "row()"). What do you do with a module that uses the Simple interface, but you want to add a feature not supported by the simple interface? You either have to convert all your code to use the real interface, mix the two, or add a feature to the Simple interface. None of those are desirable.

If there is something wrong with the "real" interface (poorly documented, difficult to understand, poorly named functions, lack of convenience functions, etc.), then let's focus our energy on making that better.

> 3) Eventually, I think we need to make the text on the
> Quick Views be
> either copyable or printable. We need to do this for
> Gramplets, too. The
> QVs being based on a doc may help with this. I have some
> (untested) code
> in there to eventually be able to create text rather than
> the gtk
> treeviews, for example.

That's what reports and exports are for. I feel like you are mixing up conventions. Gramplets and Quick Views are there to allow you to quickly *VIEW* data in Gramps. If you want to get the data out, then use the proper export or report plugin. If one doesn't exist, then let's make one.

I would support finding a way to make shortcuts from gramplets to corresponding export or report plugins. But let's not muddy the two together.

> > Does anyone else think this is a good idea?
> >
> > Is is possible to pull this off before the 3.1
> release?
>
> I'm not sure I'd say that Gramplets are fully
> mature yet... there are
> still some major things I'd like to iron out (options,
> printing, etc.) I
> think that we can simplify, and maybe create a QV-Gramplet
> hybrid that
> takes the best from both.
>
> With school starting up now, I probably won't have a
> lot of time between
> now and March. But I'd be glad to support you with
> whatever you decide.
>
> I'd recommend letting 3.1 go like it is, and thinking
> about how to better
> integrate these over the next few months.

I would support that. We can sit on this for now.

I was mostly hoping we could do some cleanup. There are still files in the src/docgen directory that are not plugins. The "docgen" name barely applies and clashes with src/plugins/docgen which does contain plugins. If we could make the "spreadsheet" classes plugins and move them to src/plugins and delete the TextBuffDoc file, then we could just delete src/docgen. For now it will just be confusing.

~Brian

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Replacing "Quick Views" with Gramplets

Reinhard Müller
Am Sonntag, den 18.01.2009, 15:25 -0800 schrieb Brian Matherly:
> I really don't like the Simple interfaces. They are very un-object
> oriented.

Somewhat offtopic, but as you talk about un-object-oriented:

I think many interfaces in Gramps are somewhat un-object-oriented, or at
least not object oriented in a way as one might expect it.

Examples:

name_displayer.display_name(my_person.get_primary_name())
--> why not my_person.get_primary_name().display_name() ?

DateHandler.displayer.display(my_date)
--> why not my_date.display() ?

ReportUtils.get_address_str(my_address)
--> why not my_address.get_str() ?

etc.

Well, just a minor rant here, nothing I would feel strong about :-)

Thanks,
Reinhard

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Replacing "Quick Views" with Gramplets

Josip
In reply to this post by Brian Matherly
Brian Matherly wrote:

> This message is mostly for Doug, but anyone is welcome to chime in...
>
> I was looking at the code that makes up the QuickViews. It it seems to be adding a lot of complexity to the Gramps code base that is redundant with the functionality provided by Gramplets. I am wondering if it would be possible to re-implement the quick views as Gramplets.
>
> Fundamentally, all we need is a way to invoke an undocked Gramplet from the right-click context menu in certain views. Then, we just need to specify which Gramplets can be envoked in which view, depending on whether the Gramplet is person, family, place, or event focused.
>
> The advantages I see are this:
>
> 1) We can remove the "Simple" interface which as far as I can tell is only used by quickviews and one Gramplet. I don't really see that the Simple interface adds much value to Gramps.
>
> 2) We can remove the TextBuffDoc interface which is a mutated orphan of a previous report format. Many functions are not implemented, and it needlessly inherits from BaseDoc.
>
> 3) Any "quick view" that you can get is also available to be docked in the Gramplet view.
>
> Does anyone else think this is a good idea?
>

As "Simple" is for newbies like me, let me say this:

SimpleAccess is for me the most understandable and documented piece of
code and is great entrance to gramps world, followed by SimpleDoc.
SimpleTable in contrary don't deserve that epithet (IMHO as newbie).
So if they don't mess with other parts of gramps code please don't
remove it.

QuickView is just copy/paste thing to quickly show results of code
writen in Sample API because it is easier to use then "real" reports and
tools. It should be named SampleView :-)
If must be replaced with gramplets be sure to keep it simple as current
basic txt gramplets, just one register function and main function for code.

--
Josip


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Replacing "Quick Views" with Gramplets

Benny Malengier
In reply to this post by Brian Matherly


2009/1/19 Brian Matherly <[hidden email]>
Doug,

Thanks for your perspective.

> I think we can do some consolidating, but maybe in slightly
> different
> ways. I like some aspects of Quick Views. Some further
> points:
>
> 1) Quick Views don't change as the active person
> changes. Makes it easy to
> compare two different ones. Gramplets can't currently
> be locked to the
> current view. (Trying to figure out an elegant way to do
> that).

If that is the only advantage of Quick Views, then surely we can fix the Gramplets to support it. I'm imagining a small padlock icon in the corner that allows the user to "lock" the gramplet so that it won't respond to callbacks from the uistate.

One of the reason of QuickViews is to allow users with little to no experience to write a small report, and give them copy/paste then so they could do something with the output.
I like the fact that copy/paste is possible in some views, having a button to output would be just as good though, as long as the quickview/gramplet writer takes into account that some people will want the data they see in the quickview/gramplet in a text file, so makes sure this functionality is there from the beginning.

My take on it is that indeed quickviews should go out and be replaced by a gramplet like structure that can be run from the context menu. It would simplify the possibilities.
So gramplets should then also need to register if they are person/all persons/family/database/... /read/write oriented to allow them to pop up in the right place.
A possible extension for the future that we can then add a gramplet tab to the editors.

 

> 2) I really like the Simple interfaces! In fact, I wished
> that they were
> part of the "regular" interface, or better
> integrated. There are some
> really good ideas in there, for beginners and experts.

I really don't like the Simple interfaces. They are very un-object oriented. They obscure functionality from the user (which is not the same as "hiding complexity"). They are poorly documented. Some function names aren't even verbs (like "row()"). What do you do with a module that uses the Simple interface, but you want to add a feature not supported by the simple interface? You either have to convert all your code to use the real interface, mix the two, or add a feature to the Simple interface. None of those are desirable.

If there is something wrong with the "real" interface (poorly documented, difficult to understand, poorly named functions, lack of convenience functions, etc.), then let's focus our energy on making that better.

Don created it to allow people with little knowledge of the rest of GRAMPS (eg options, database structure) to create something small quickly. This need comes up from time to time, so it has it usage. I suppose the core developers should not use the simple interfaces except for a few examples to the aspiring newbie report writer.
 

> 3) Eventually, I think we need to make the text on the
> Quick Views be
> either copyable or printable. We need to do this for
> Gramplets, too. The
> QVs being based on a doc may help with this. I have some
> (untested) code
> in there to eventually be able to create text rather than
> the gtk
> treeviews, for example.

That's what reports and exports are for. I feel like you are mixing up conventions. Gramplets and Quick Views are there to allow you to quickly *VIEW* data in Gramps. If you want to get the data out, then use the proper export or report plugin. If one doesn't exist, then let's make one.

I would support finding a way to make shortcuts from gramplets to corresponding export or report plugins. But let's not muddy the two together.

As said, quick views where intended for the users to make their own report quickly without knowing the basics, so the copy paste argument was important.


> > Does anyone else think this is a good idea?
> >
> > Is is possible to pull this off before the 3.1
> release?
>
> I'm not sure I'd say that Gramplets are fully
> mature yet... there are
> still some major things I'd like to iron out (options,
> printing, etc.) I
> think that we can simplify, and maybe create a QV-Gramplet
> hybrid that
> takes the best from both.
>
> With school starting up now, I probably won't have a
> lot of time between
> now and March. But I'd be glad to support you with
> whatever you decide.
>
> I'd recommend letting 3.1 go like it is, and thinking
> about how to better
> integrate these over the next few months.

I would support that. We can sit on this for now.

I was mostly hoping we could do some cleanup. There are still files in the src/docgen directory that are not plugins. The "docgen" name barely applies and clashes with src/plugins/docgen which does contain plugins. If we could make the "spreadsheet" classes plugins and move them to src/plugins and delete the TextBuffDoc file, then we could just delete src/docgen. For now it will just be confusing.

I support the cleanup, but do believe some easy interface can have its uses. You are right though, a very good documentation of the data structure with the real API might be a better investment of our time.

Benny


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Replacing "Quick Views" with Gramplets

Gary Burton

> A possible extension for the future that we can then add a gramplet tab to the editors.

The DataViews have an optional filter side panel. I was wondering how much work it would be to implement a  Gramplet side panel which could be used as a place to dock a Gramplet or two.

Bye

Gary



     


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Replacing "Quick Views" with Gramplets

Brian Matherly
Gary,

> > A possible extension for the future that we can then
> add a gramplet tab to the editors.
>
> The DataViews have an optional filter side panel. I was
> wondering how much work it would be to implement a  Gramplet
> side panel which could be used as a place to dock a Gramplet
> or two.
>
> Bye
>
> Gary

You can already do this if you:

1) Un-maximize Gramps and drag the right side of the application to the left so that there are a couple of inches on the right of the screen that don't have any application on them.

2) Un-dock a gramplet and place it in that empty space on the right side of the screen.

That's what I do and it works great. I can stack two Gramplets on top of each other.

~Brian

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Replacing "Quick Views" with Gramplets

Gary Burton
> You can already do this if you:
>
> 1) Un-maximize Gramps and drag the right side of the application to the left so
> that there are a couple of inches on the right of the screen that don't have any
> application on them.
>
> 2) Un-dock a gramplet and place it in that empty space on the right side of the
> screen.
>
> That's what I do and it works great. I can stack two Gramplets on top of each
> other.

I know it's possible to do this, but it just feels a bit like a work-around to me bringing the gramplet window outside of the main Gramps window.

Bye

Gary



     


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Replacing "Quick Views" with Gramplets

Douglas S. Blank
>> You can already do this if you:
>>
>> 1) Un-maximize Gramps and drag the right side of the application to the
>> left so
>> that there are a couple of inches on the right of the screen that don't
>> have any
>> application on them.
>>
>> 2) Un-dock a gramplet and place it in that empty space on the right side
>> of the
>> screen.
>>
>> That's what I do and it works great. I can stack two Gramplets on top of
>> each
>> other.
>
> I know it's possible to do this, but it just feels a bit like a
> work-around to me bringing the gramplet window outside of the main Gramps
> window.

I think this is a good idea that brings up some limitations of Gramplets
(they don't remember their detached size or location). A thought: what if
everything was positionable, and users created their own tab/views?

Just thinking out loud... will let these ideas bounce around for the next
few months and think of a way forward...

-Doug

> Bye
>
> Gary


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel