Use of Karbon canvas in KoPACanvas

Dear list,
        Kivio and KPresenter have a very annoying problem with their canvas
implementation: they display the page and a border around it, in which you can
move shapes around it. This is extremely distracting and annoying.

        Karbon in the other hand has "Infinite canvas", this is very desirable in my
opinion and feels much more natural.

        So, can we somehow change the KoPACanvas implementation to resemble
Karbon's? can we have a hierarchy class somehow to prevent code duplication?
are there any assumptions that prevent this from happening? should we just
provide another implementation of the same feature for the PA ignoring
Karbon's altogether? and finally, is it as desirable for you as it is for me?

        I understand that it is of not much use having an infinite canvas on a
printing-oriented application, such as Kivio, because anything outside the
page will not be printed. However, the current state is confusing and
distracting (having a rectangle resemble the page inside another white
rectangle feels weird to me). Falling back to clipping the shapes to the
page's size is even more annoying.

Carlos
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

[Jaroslaw Staniek-3]

2009/10/26 Carlos Licea <carlos_licea@...>:

> Dear list,
>        Kivio and KPresenter have a very annoying problem with their canvas
> implementation: they display the page and a border around it, in which you can
> move shapes around it. This is extremely distracting and annoying.
>
>        Karbon in the other hand has "Infinite canvas", this is very desirable in my
> opinion and feels much more natural.
>
>        So, can we somehow change the KoPACanvas implementation to resemble
> Karbon's? can we have a hierarchy class somehow to prevent code duplication?
> are there any assumptions that prevent this from happening? should we just
> provide another implementation of the same feature for the PA ignoring
> Karbon's altogether? and finally, is it as desirable for you as it is for me?
>
>        I understand that it is of not much use having an infinite canvas on a
> printing-oriented application, such as Kivio, because anything outside the
> page will not be printed.

IMO: While in KPresenter it's generally good to know the screen
boudnaries, in case of Kivio-like apps one use case is that the user
does not want to be distracted by the boundaried and instead draw the
diagram freely in the infinite area, then define the page boundaries
as the very last step, if ever (perhaps the app can define it
automatically on priniting/exporting). I am thinking about one that
draws a diagram, e.g. block diagram, and never knows how big it will
be - infinite area helps in this case.


--
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
 KDE Libraries for MS Windows (http://windows.kde.org)
 http://www.linkedin.com/in/jstaniek
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Mon, Oct 26, 2009 at 10:41 PM, Carlos Licea <carlos_licea@...> wrote:

Dear list,
       Kivio and KPresenter have a very annoying problem with their canvas
implementation: they display the page and a border around it, in which you can
move shapes around it. This is extremely distracting and annoying.

       Karbon in the other hand has "Infinite canvas", this is very desirable in my
opinion and feels much more natural.

       So, can we somehow change the KoPACanvas implementation to resemble
Karbon's? can we have a hierarchy class somehow to prevent code duplication?
are there any assumptions that prevent this from happening? should we just
provide another implementation of the same feature for the PA ignoring
Karbon's altogether? and finally, is it as desirable for you as it is for me?

       I understand that it is of not much use having an infinite canvas on a
printing-oriented application, such as Kivio, because anything outside the
page will not be printed. However, the current state is confusing and
distracting (having a rectangle resemble the page inside another white
rectangle feels weird to me). Falling back to clipping the shapes to the
page's size is even more annoying.

Carlos

You could do it like Krita does: In Krita we have a infinite canvas, but only draw the stuff insid the image.

The first step would be the set the canvas mode to infinite in the canvas controller of the kopageapp view.
Then you have a canvas where you can move shapes anywhere. After that you need fix the page so that it's drawn at the right place and only the area inside the page is drawn white and the outside with the background. Bonus would be with a page shadow.

The tricky part is to get the page draw correctly (at least it was in Krita)

_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Mon October 26 2009, Carlos Licea wrote:
> Dear list,
> Kivio and KPresenter have a very annoying problem with their canvas
> implementation: they display the page and a border around it, in which you
>  can move shapes around it. This is extremely distracting and annoying.

For me the bigger canvas has the plus that you can put stuff out of the way
when you are working on other things.
>
> Karbon in the other hand has "Infinite canvas", this is very desirable in
>  my opinion and feels much more natural.
>
I have to agree that a growing canvas is more natural.

> So, can we somehow change the KoPACanvas implementation to resemble
> Karbon's? can we have a hierarchy class somehow to prevent code
>  duplication? are there any assumptions that prevent this from happening?
>  should we just provide another implementation of the same feature for the
>  PA ignoring Karbon's altogether? and finally, is it as desirable for you
>  as it is for me?

I think it is not possible to use Karbons canvas inside kopageapp due to
different needs. However it might be possible to have more code to handle
infinite canvas inside the canvas controller so that every app which wants to
use an infinite canvas finds it easy to do so.

> I understand that it is of not much use having an infinite canvas on a
> printing-oriented application, such as Kivio, because anything outside the
> page will not be printed. However, the current state is confusing and
> distracting (having a rectangle resemble the page inside another white
> rectangle feels weird to me).

That is the same in karbon.

I think a canvas that does the same as the the karbon canvas, growing when
there is stuff put outside would be the best also for kopageapp. I worked on
that too. However due to the feature freeze I was not able to complete it and
have gone with the solution we have at the moment.
It should also be possible to paint the background outside the page rect with
a different color to make it more obvious that it is outside of the page. I
did not do this for the current version as it would be quite stange for the
user to be able to move it outside the page but at one point moving it more
would not be possible due to being of the canvas.

Note that it is quite possible in ODF to have shapes outside of the page rect.
For that case it should also be possible to see them and be able to use them.

> Falling back to clipping the shapes to the
> page's size is even more annoying.

I think an option to resize the shapes to fit into a given page size as
Jaroslaw has proposed would be very nice especially for kivio.

Thorsten
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

> IMO: While in KPresenter it's generally good to know the screen
> boudnaries, in case of Kivio-like apps one use case is that the user
> does not want to be distracted by the boundaried and instead draw the
> diagram freely in the infinite area, then define the page boundaries
> as the very last step, if ever (perhaps the app can define it
> automatically on priniting/exporting). I am thinking about one that
> draws a diagram, e.g. block diagram, and never knows how big it will
> be - infinite area helps in this case.
I don't think that such a workflow is desirable. When doing a diagram most of
the time you *are* concerned on how it looks on the page.
However, I had already considered the case of the change of the paper size. I
think that the application redistributing and resizing all the shapes and
adapting itself automatically to such changes would be much more useful.

Carlos
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Lunes 26 Octubre 2009 21:42:54 Thorsten Zachmann escribió:

> On Mon October 26 2009, Carlos Licea wrote:
> > Dear list,
> > Kivio and KPresenter have a very annoying problem with their canvas
> > implementation: they display the page and a border around it, in which
> > you can move shapes around it. This is extremely distracting and
> > annoying.
>
> For me the bigger canvas has the plus that you can put stuff out of the way
> when you are working on other things.
>
> > Karbon in the other hand has "Infinite canvas", this is very desirable
> > in my opinion and feels much more natural.
>
> I have to agree that a growing canvas is more natural.
>
> > So, can we somehow change the KoPACanvas implementation to resemble
> > Karbon's? can we have a hierarchy class somehow to prevent code
> >  duplication? are there any assumptions that prevent this from happening?
> >  should we just provide another implementation of the same feature for
> > the PA ignoring Karbon's altogether? and finally, is it as desirable for
> > you as it is for me?
>
> I think it is not possible to use Karbons canvas inside kopageapp due to
> different needs. However it might be possible to have more code to handle
> infinite canvas inside the canvas controller so that every app which wants
>  to use an infinite canvas finds it easy to do so.
>
> > I understand that it is of not much use having an infinite canvas on a
> > printing-oriented application, such as Kivio, because anything outside
> > the page will not be printed. However, the current state is confusing and
> > distracting (having a rectangle resemble the page inside another white
> > rectangle feels weird to me).
>
> That is the same in karbon.
>
> I think a canvas that does the same as the the karbon canvas, growing when
> there is stuff put outside would be the best also for kopageapp. I worked
>  on that too. However due to the feature freeze I was not able to complete
>  it and have gone with the solution we have at the moment.
> It should also be possible to paint the background outside the page rect
>  with a different color to make it more obvious that it is outside of the
>  page. I did not do this for the current version as it would be quite
>  stange for the user to be able to move it outside the page but at one
>  point moving it more would not be possible due to being of the canvas.
>
> Note that it is quite possible in ODF to have shapes outside of the page
>  rect. For that case it should also be possible to see them and be able to
>  use them.
>
> > Falling back to clipping the shapes to the
> > page's size is even more annoying.
>
> I think an option to resize the shapes to fit into a given page size as
> Jaroslaw has proposed would be very nice especially for kivio.
>

So after reading all the mail I still can't extract the way to proceed. Will
you continue to work on the infinite canvas for KoPA?.

Also, with respect to the page-less kivio, I don't think it is a proper
workflow, as I responded to Jaroslaw, you *do* care how the diagram looks on
paper. The change of the paper size could trigger a repositioning and
rescaling of the shapes on the page (according to some Magic Algorith TM ;-)).

Carlos
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Mon October 26 2009, Sven Langkamp wrote:
> You could do it like Krita does: In Krita we have a infinite canvas, but
> only draw the stuff insid the image.
>

That would make it very hard to select stuff that is outside of the page.

Thorsten
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel