From alexandre.prokoudine at gmail.com  Thu May 12 12:21:50 2011
From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine)
Date: Thu, 12 May 2011 16:21:50 +0400
Subject: [scribus-dev] gsoc blogs
Message-ID: <BANLkTikeXpBrLbZnfZ2BgW3JmX+bonH1eA@mail.gmail.com>

Hi,

I've just added http://scripter2.jainbasil.net to graphicsplanet.org
aggregation, the server will pick it up in a couple of hours. Is the
second student planning to blog?

Alexandre Prokoudine
http://libregraphicsworld.org


From elvstone at gmail.com  Thu May 12 14:18:40 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Thu, 12 May 2011 16:18:40 +0200
Subject: [scribus-dev] gsoc blogs
In-Reply-To: <BANLkTikeXpBrLbZnfZ2BgW3JmX+bonH1eA@mail.gmail.com>
References: <BANLkTikeXpBrLbZnfZ2BgW3JmX+bonH1eA@mail.gmail.com>
Message-ID: <BANLkTi=qzQC3V0x-H_fX1uPab+MfoPQFMg@mail.gmail.com>

2011/5/12 Alexandre Prokoudine <alexandre.prokoudine at gmail.com>:
> Hi,
>
> I've just added http://scripter2.jainbasil.net to graphicsplanet.org
> aggregation, the server will pick it up in a couple of hours. Is the
> second student planning to blog?

Absolutely. And just like I did during my GSoC in 2009, I'll tag all
such posts with 'gsoc', so use the following URL for aggregation:

http://estan.dose.se/tag/gsoc/feed

Regards,
Elvis

>
> Alexandre Prokoudine
> http://libregraphicsworld.org
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From alexandre.prokoudine at gmail.com  Thu May 12 14:23:56 2011
From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine)
Date: Thu, 12 May 2011 18:23:56 +0400
Subject: [scribus-dev] gsoc blogs
In-Reply-To: <BANLkTi=qzQC3V0x-H_fX1uPab+MfoPQFMg@mail.gmail.com>
References: <BANLkTikeXpBrLbZnfZ2BgW3JmX+bonH1eA@mail.gmail.com>
	<BANLkTi=qzQC3V0x-H_fX1uPab+MfoPQFMg@mail.gmail.com>
Message-ID: <BANLkTimaiR8iiNpjLWcQ0KYXGUNomKSGag@mail.gmail.com>

On Thu, May 12, 2011 at 6:18 PM, Elvis Stansvik wrote:

>> I've just added http://scripter2.jainbasil.net to graphicsplanet.org
>> aggregation, the server will pick it up in a couple of hours. Is the
>> second student planning to blog?
>
> Absolutely. And just like I did during my GSoC in 2009, I'll tag all
> such posts with 'gsoc', so use the following URL for aggregation:
>
> http://estan.dose.se/tag/gsoc/feed

Thanks! Committed, pushed. Will be online in few hours.

Alexandre Prokoudine
http://libregraphicsworld.org


From elvstone at gmail.com  Thu May 12 14:26:11 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Thu, 12 May 2011 16:26:11 +0200
Subject: [scribus-dev] gsoc blogs
In-Reply-To: <BANLkTimaiR8iiNpjLWcQ0KYXGUNomKSGag@mail.gmail.com>
References: <BANLkTikeXpBrLbZnfZ2BgW3JmX+bonH1eA@mail.gmail.com>
	<BANLkTi=qzQC3V0x-H_fX1uPab+MfoPQFMg@mail.gmail.com>
	<BANLkTimaiR8iiNpjLWcQ0KYXGUNomKSGag@mail.gmail.com>
Message-ID: <BANLkTinn-Xpenz-ar=sMPHE7RqimjYU4CQ@mail.gmail.com>

2011/5/12 Alexandre Prokoudine <alexandre.prokoudine at gmail.com>:
> On Thu, May 12, 2011 at 6:18 PM, Elvis Stansvik wrote:
>
>>> I've just added http://scripter2.jainbasil.net to graphicsplanet.org
>>> aggregation, the server will pick it up in a couple of hours. Is the
>>> second student planning to blog?
>>
>> Absolutely. And just like I did during my GSoC in 2009, I'll tag all
>> such posts with 'gsoc', so use the following URL for aggregation:
>>
>> http://estan.dose.se/tag/gsoc/feed
>
> Thanks! Committed, pushed. Will be online in few hours.

Great. Thanks.

Elvis

>
> Alexandre Prokoudine
> http://libregraphicsworld.org
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From elvstone at gmail.com  Sun May 15 16:58:15 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Sun, 15 May 2011 18:58:15 +0200
Subject: [scribus-dev] Preparations for GSoC
Message-ID: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>

Hello Scribus folks,

Summer is getting closer fast, and while I'm exceedingly busy with
preparations for my upcoming exams, I think it's important I get at
least some preparations for GSoC done so that I can get a flying start
and have a clear direction for my project once May 28 comes and exams
are over. I've started to write down some preliminary questions and
thoughts around my project and put them on the wiki [1], but I'll
include that page almost verbatim below, sans some of the wiki markup,
so that we can discuss it on-list. The wiki has a couple of
screenshots from Indesign, so perhaps you'll still want to check that
out. I'll extend/update the page as my project progresses.

I would be very grateful if you could read through these questions
once and give your comments. I'm especially interested in things where
you feel "no no no, not like that", or if there are things where you
know things will get hairy technically. I think it's important we're
on the same page regarding how the tables should work in Scribus from
the get-go, so any and all input is relevant.

Lastly, in the midst of everything I believe I've never asked who will
be my mentor this summer, might be good to know :) Malex? MrB?

Best regards,
Elvis

[1] http://wiki.scribus.net/canvas/GSoC_2011_Tables

= GSoC 2011 Tables =
This page contains technical and functionality related considerations
regarding the implementation of tables in Scribus as part of Google
Summer of Code 2011. Here I'll try to keep an up to date document
describing the design of the implementation, a list of open technical
problems and questions regarding the functionality of the tables,
including a couple of use cases as well as everything else concerning
my work on bringing tables support to Scribus.

== General Design ==
As was outlined briefly in my project proposal, the tables in Scribus
will be implemented as a new page item. Handling of cell content will
be delegated to text frames.

== Interaction Questions ==
In the questions below, I refer quite a lot to Adobe Indesign. This is
not because I see it as a template of good design or anything, it's
just that I happen to have come across a copy of it which I have
running under VirtualBox, and it helps to have something existing to
discuss around.

=== Table Creation/Editing ===
Is there a general consensus on how we want interaction with the
tables to work? Looking at how tables work in Indesign CS5.5, their
design is quite straight forward and works essentially as those found
in word processors: The user is presented with a "Table" menu from
which tables can be inserted and manipulated and formatted through
dialogs that pop up. Something that might be different from how tables
will work in Scribus is that in Indesign, tables can only exist as
inline objects inside a text frame, not as objects on their own.

I'm imagining that in Scribus, the user is able to freely position the
tables on the page, while in the future, we can hopefully let the user
insert the table item I'll be creating inline in running text by
making it an inline object of some kind? Another thing which I think
will naturally be different in Scribus is that in Scribus, editing of
item properties is mostly done through the Properties palette, and not
so much through dialogs that pop up (thankfully! because table editing
in Indesign seems to be very dialog-intense). I guess we will have a
new tab on the PP called "Table" that will be disabled unless a table
is selected, similar to how it works for images?

=== Table/Row/Column Resizing ===
In Indesign, tables, rows and columns are resized by click-dragging,
and I'm guessing this is how we want it to work in Scribus too?
Something that comes to mind is that for most items Scribus uses a
modal way of interacting with the item: In the "normal" mode, the user
is able to select, move and resize an item, while in the "editing"
mode (entered by double-clicking) he/she is able to perform editing
actions on the item, such as inserting text in text frames, or moving
vertices of a polygon. Is this modal way of working something we want
for tables as well, in order for them to fit in with the Scribus way
of working? If so, I'm guessing actions such as column/row resizing
should be available in the "editing" mode, while in the "normal" mode
the user is only able to move/resize the table?

=== Styles ===
A while ago I took an afternoon and investigated what it takes to
create a new kind of style in Scribus, thinking this is something we
might want for tables. It was mostly straight forward and I ended up
with a primitive skeleton of a new style which is now in my Git repo.
Since then however, I've started thinking; Are styles for tables (and
even for rows/columns/cells) something we really want, or are they an
unnecessary complication for small benefits? I don't know about other
programs, but Indesign does not have named styles for tables. Tables
are simply formatted by direct editing of properties for individual
tables. How common are use cases where the user would really be
hampered without support for named table (and possibly
cell/row/column) styles? Would it be sufficient for Scribus if editing
table properties is a per-table operation? I'd really like to get the
opinion of other team members on this.

=== Cell Selection ===
I'm guessing we want cell selection to work similar to word processors
and Indesign, where a user is able to enter a "cell selection" mode by
starting to select some text in a cell with the mouse and then
dragging outside the cell boundaries?

== Technical Questions ==
Below are some of the technical questions I have to find answers to.
Since the content of table cells will be represented using Scribus'
regular text frames, several of the questions below are related to
this.

=== Notification of Text Overflow in Text Frames ===
Using text frames for cell content means the table will have to be
notified when overflow occurs in a text frame, to be able to correctly
re-layout the table starting from the row in which the overflow
occurred. If we eventually want to have width-growing columns, we'll
also need a way to be notified when a line break is about to occur in
a text frame. So the question is; do text frames currently emit any
signals to indicate that content is overflowing? It seems they are
not, but one place where such a signal could possibly be emitted is in
PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might
not be a correct solution though, perhaps the table should instead
listen to insertions being made in the text frame, and query the frame
for its overflow state using PageItem::frameOverflows()?

In addition to being notified of when overflow happens, the table will
also need to be able to query the text frame for the height of its
content, to be able to resize it correctly during table layout. Is
this possible using the current API? If not, what would it take to add
it?

=== Editing of Cell Content ===
As the text frames have their own modal way of being edited, and on
top of that we'll probably have a modal way of editing tables (see
above under Interaction Questions), how will we combine the two when
it comes to editing cell content? I really don't think we want a
multi-layered modal interaction, where the user first has to
double-click the table, and then again double-click a cell in order to
edit its content. Indesign is on the other extreme of this, there a
user can directly edit the content of a table, without any modes of
operation. I think what we want in Scribus is for the user to
immediately be able to interact with the content of cells after the
first double-click on the table. Or what do you think?

On top of this is the question of keyboard navigation between cells,
which I'm sure we want. The table will probably have to somehow filter
the keyboard events before they hit the underlying text frame of the
cell in order to get this to work.

=== Disabling Decorations / Resize Handles of Text Frames ===
I will have to figure out how drawing of decorations, and possibly
also the resize handles of text frames can be disabled. The table will
only be interested in the text displaying / editing capabilities of
the text frames, and will not want them to draw anything else such as
borders, decorations or resize handles. Perhaps this is an easy thing,
but still something I'll have to investigate.


From lrosenth at adobe.com  Sun May 15 17:29:50 2011
From: lrosenth at adobe.com (Leonard Rosenthol)
Date: Sun, 15 May 2011 10:29:50 -0700
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
Message-ID: <D23D6B9E57D654429A9AB6918CACEAA98060741F69@NAMBX02.corp.adobe.com>

Some comments/corrections on Tables and InDesign.

>Something that might be different from how tables
>will work in Scribus is that in Indesign, tables can only exist as
>inline objects inside a text frame, not as objects on their own.
>
That's because by having them as part of a text frame, you can then have other things wrap around them and they act "inline".  Having a "table frame" doesn't really fit the model that most users are used to - it also makes it more complex to implement when you start thinking inline.  It also helps with selects that cross the table boundary (eg. Some text and some table).


>Another thing which I think
>will naturally be different in Scribus is that in Scribus, editing of
>item properties is mostly done through the Properties palette, and not
>so much through dialogs that pop up (thankfully! because table editing
>in Indesign seems to be very dialog-intense).
>
This is where your inexperience with InDesign shows :).  If you look closely, you will see that it's properties bar enables full control w/o ever seeing a single dialog.  And if you don't like the bar, you can also show the Table Palette (floating or docked) and change things there too...


>In Indesign, tables, rows and columns are resized by click-dragging,
>and I'm guessing this is how we want it to work in Scribus too?
>
You can also type explicit values into the properties bar or palette.


>In Indesign, tables, rows and columns are resized by click-dragging,
>and I'm guessing this is how we want it to work in Scribus too?
>
Not only does InDesign have named styles for an entire table, we also have Cell styles for individual cells (or groups of them, such as Rows or Columns).


>In Indesign, tables, rows and columns are resized by click-dragging,
>and I'm guessing this is how we want it to work in Scribus too?
>
Don't forget individual row and column selection as well. 


>Using text frames for cell content
>
While this is one of the most common first pass methods for how to do tables - you may (will) find that it doesn't work well when you wish to enable cross-cell and cross-table selection and manipulation.  


Hope that helps....

Leonard

-----Original Message-----
From: Elvis Stansvik [mailto:elvstone at gmail.com] 
Sent: Sunday, May 15, 2011 9:58 AM
To: Scribus Development Mailing List
Subject: [scribus-dev] Preparations for GSoC

Hello Scribus folks,

Summer is getting closer fast, and while I'm exceedingly busy with
preparations for my upcoming exams, I think it's important I get at
least some preparations for GSoC done so that I can get a flying start
and have a clear direction for my project once May 28 comes and exams
are over. I've started to write down some preliminary questions and
thoughts around my project and put them on the wiki [1], but I'll
include that page almost verbatim below, sans some of the wiki markup,
so that we can discuss it on-list. The wiki has a couple of
screenshots from Indesign, so perhaps you'll still want to check that
out. I'll extend/update the page as my project progresses.

I would be very grateful if you could read through these questions
once and give your comments. I'm especially interested in things where
you feel "no no no, not like that", or if there are things where you
know things will get hairy technically. I think it's important we're
on the same page regarding how the tables should work in Scribus from
the get-go, so any and all input is relevant.

Lastly, in the midst of everything I believe I've never asked who will
be my mentor this summer, might be good to know :) Malex? MrB?

Best regards,
Elvis

[1] http://wiki.scribus.net/canvas/GSoC_2011_Tables

= GSoC 2011 Tables =
This page contains technical and functionality related considerations
regarding the implementation of tables in Scribus as part of Google
Summer of Code 2011. Here I'll try to keep an up to date document
describing the design of the implementation, a list of open technical
problems and questions regarding the functionality of the tables,
including a couple of use cases as well as everything else concerning
my work on bringing tables support to Scribus.

== General Design ==
As was outlined briefly in my project proposal, the tables in Scribus
will be implemented as a new page item. Handling of cell content will
be delegated to text frames.

== Interaction Questions ==
In the questions below, I refer quite a lot to Adobe Indesign. This is
not because I see it as a template of good design or anything, it's
just that I happen to have come across a copy of it which I have
running under VirtualBox, and it helps to have something existing to
discuss around.

=== Table Creation/Editing ===
Is there a general consensus on how we want interaction with the
tables to work? Looking at how tables work in Indesign CS5.5, their
design is quite straight forward and works essentially as those found
in word processors: The user is presented with a "Table" menu from
which tables can be inserted and manipulated and formatted through
dialogs that pop up. Something that might be different from how tables
will work in Scribus is that in Indesign, tables can only exist as
inline objects inside a text frame, not as objects on their own.

I'm imagining that in Scribus, the user is able to freely position the
tables on the page, while in the future, we can hopefully let the user
insert the table item I'll be creating inline in running text by
making it an inline object of some kind? Another thing which I think
will naturally be different in Scribus is that in Scribus, editing of
item properties is mostly done through the Properties palette, and not
so much through dialogs that pop up (thankfully! because table editing
in Indesign seems to be very dialog-intense). I guess we will have a
new tab on the PP called "Table" that will be disabled unless a table
is selected, similar to how it works for images?

=== Table/Row/Column Resizing ===
In Indesign, tables, rows and columns are resized by click-dragging,
and I'm guessing this is how we want it to work in Scribus too?
Something that comes to mind is that for most items Scribus uses a
modal way of interacting with the item: In the "normal" mode, the user
is able to select, move and resize an item, while in the "editing"
mode (entered by double-clicking) he/she is able to perform editing
actions on the item, such as inserting text in text frames, or moving
vertices of a polygon. Is this modal way of working something we want
for tables as well, in order for them to fit in with the Scribus way
of working? If so, I'm guessing actions such as column/row resizing
should be available in the "editing" mode, while in the "normal" mode
the user is only able to move/resize the table?

=== Styles ===
A while ago I took an afternoon and investigated what it takes to
create a new kind of style in Scribus, thinking this is something we
might want for tables. It was mostly straight forward and I ended up
with a primitive skeleton of a new style which is now in my Git repo.
Since then however, I've started thinking; Are styles for tables (and
even for rows/columns/cells) something we really want, or are they an
unnecessary complication for small benefits? I don't know about other
programs, but Indesign does not have named styles for tables. Tables
are simply formatted by direct editing of properties for individual
tables. How common are use cases where the user would really be
hampered without support for named table (and possibly
cell/row/column) styles? Would it be sufficient for Scribus if editing
table properties is a per-table operation? I'd really like to get the
opinion of other team members on this.

=== Cell Selection ===
I'm guessing we want cell selection to work similar to word processors
and Indesign, where a user is able to enter a "cell selection" mode by
starting to select some text in a cell with the mouse and then
dragging outside the cell boundaries?

== Technical Questions ==
Below are some of the technical questions I have to find answers to.
Since the content of table cells will be represented using Scribus'
regular text frames, several of the questions below are related to
this.

=== Notification of Text Overflow in Text Frames ===
Using text frames for cell content means the table will have to be
notified when overflow occurs in a text frame, to be able to correctly
re-layout the table starting from the row in which the overflow
occurred. If we eventually want to have width-growing columns, we'll
also need a way to be notified when a line break is about to occur in
a text frame. So the question is; do text frames currently emit any
signals to indicate that content is overflowing? It seems they are
not, but one place where such a signal could possibly be emitted is in
PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might
not be a correct solution though, perhaps the table should instead
listen to insertions being made in the text frame, and query the frame
for its overflow state using PageItem::frameOverflows()?

In addition to being notified of when overflow happens, the table will
also need to be able to query the text frame for the height of its
content, to be able to resize it correctly during table layout. Is
this possible using the current API? If not, what would it take to add
it?

=== Editing of Cell Content ===
As the text frames have their own modal way of being edited, and on
top of that we'll probably have a modal way of editing tables (see
above under Interaction Questions), how will we combine the two when
it comes to editing cell content? I really don't think we want a
multi-layered modal interaction, where the user first has to
double-click the table, and then again double-click a cell in order to
edit its content. Indesign is on the other extreme of this, there a
user can directly edit the content of a table, without any modes of
operation. I think what we want in Scribus is for the user to
immediately be able to interact with the content of cells after the
first double-click on the table. Or what do you think?

On top of this is the question of keyboard navigation between cells,
which I'm sure we want. The table will probably have to somehow filter
the keyboard events before they hit the underlying text frame of the
cell in order to get this to work.

=== Disabling Decorations / Resize Handles of Text Frames ===
I will have to figure out how drawing of decorations, and possibly
also the resize handles of text frames can be disabled. The table will
only be interested in the text displaying / editing capabilities of
the text frames, and will not want them to draw anything else such as
borders, decorations or resize handles. Perhaps this is an easy thing,
but still something I'll have to investigate.

_______________________________________________
scribus-dev mailing list
scribus-dev at lists.scribus.net
http://lists.scribus.net/mailman/listinfo/scribus-dev


From lrosenth at adobe.com  Sun May 15 17:29:50 2011
From: lrosenth at adobe.com (Leonard Rosenthol)
Date: Sun, 15 May 2011 10:29:50 -0700
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
Message-ID: <D23D6B9E57D654429A9AB6918CACEAA98060741F69@NAMBX02.corp.adobe.com>

Some comments/corrections on Tables and InDesign.

>Something that might be different from how tables
>will work in Scribus is that in Indesign, tables can only exist as
>inline objects inside a text frame, not as objects on their own.
>
That's because by having them as part of a text frame, you can then have other things wrap around them and they act "inline".  Having a "table frame" doesn't really fit the model that most users are used to - it also makes it more complex to implement when you start thinking inline.  It also helps with selects that cross the table boundary (eg. Some text and some table).


>Another thing which I think
>will naturally be different in Scribus is that in Scribus, editing of
>item properties is mostly done through the Properties palette, and not
>so much through dialogs that pop up (thankfully! because table editing
>in Indesign seems to be very dialog-intense).
>
This is where your inexperience with InDesign shows :).  If you look closely, you will see that it's properties bar enables full control w/o ever seeing a single dialog.  And if you don't like the bar, you can also show the Table Palette (floating or docked) and change things there too...


>In Indesign, tables, rows and columns are resized by click-dragging,
>and I'm guessing this is how we want it to work in Scribus too?
>
You can also type explicit values into the properties bar or palette.


>In Indesign, tables, rows and columns are resized by click-dragging,
>and I'm guessing this is how we want it to work in Scribus too?
>
Not only does InDesign have named styles for an entire table, we also have Cell styles for individual cells (or groups of them, such as Rows or Columns).


>In Indesign, tables, rows and columns are resized by click-dragging,
>and I'm guessing this is how we want it to work in Scribus too?
>
Don't forget individual row and column selection as well. 


>Using text frames for cell content
>
While this is one of the most common first pass methods for how to do tables - you may (will) find that it doesn't work well when you wish to enable cross-cell and cross-table selection and manipulation.  


Hope that helps....

Leonard

-----Original Message-----
From: Elvis Stansvik [mailto:elvstone at gmail.com] 
Sent: Sunday, May 15, 2011 9:58 AM
To: Scribus Development Mailing List
Subject: [scribus-dev] Preparations for GSoC

Hello Scribus folks,

Summer is getting closer fast, and while I'm exceedingly busy with
preparations for my upcoming exams, I think it's important I get at
least some preparations for GSoC done so that I can get a flying start
and have a clear direction for my project once May 28 comes and exams
are over. I've started to write down some preliminary questions and
thoughts around my project and put them on the wiki [1], but I'll
include that page almost verbatim below, sans some of the wiki markup,
so that we can discuss it on-list. The wiki has a couple of
screenshots from Indesign, so perhaps you'll still want to check that
out. I'll extend/update the page as my project progresses.

I would be very grateful if you could read through these questions
once and give your comments. I'm especially interested in things where
you feel "no no no, not like that", or if there are things where you
know things will get hairy technically. I think it's important we're
on the same page regarding how the tables should work in Scribus from
the get-go, so any and all input is relevant.

Lastly, in the midst of everything I believe I've never asked who will
be my mentor this summer, might be good to know :) Malex? MrB?

Best regards,
Elvis

[1] http://wiki.scribus.net/canvas/GSoC_2011_Tables

= GSoC 2011 Tables =
This page contains technical and functionality related considerations
regarding the implementation of tables in Scribus as part of Google
Summer of Code 2011. Here I'll try to keep an up to date document
describing the design of the implementation, a list of open technical
problems and questions regarding the functionality of the tables,
including a couple of use cases as well as everything else concerning
my work on bringing tables support to Scribus.

== General Design ==
As was outlined briefly in my project proposal, the tables in Scribus
will be implemented as a new page item. Handling of cell content will
be delegated to text frames.

== Interaction Questions ==
In the questions below, I refer quite a lot to Adobe Indesign. This is
not because I see it as a template of good design or anything, it's
just that I happen to have come across a copy of it which I have
running under VirtualBox, and it helps to have something existing to
discuss around.

=== Table Creation/Editing ===
Is there a general consensus on how we want interaction with the
tables to work? Looking at how tables work in Indesign CS5.5, their
design is quite straight forward and works essentially as those found
in word processors: The user is presented with a "Table" menu from
which tables can be inserted and manipulated and formatted through
dialogs that pop up. Something that might be different from how tables
will work in Scribus is that in Indesign, tables can only exist as
inline objects inside a text frame, not as objects on their own.

I'm imagining that in Scribus, the user is able to freely position the
tables on the page, while in the future, we can hopefully let the user
insert the table item I'll be creating inline in running text by
making it an inline object of some kind? Another thing which I think
will naturally be different in Scribus is that in Scribus, editing of
item properties is mostly done through the Properties palette, and not
so much through dialogs that pop up (thankfully! because table editing
in Indesign seems to be very dialog-intense). I guess we will have a
new tab on the PP called "Table" that will be disabled unless a table
is selected, similar to how it works for images?

=== Table/Row/Column Resizing ===
In Indesign, tables, rows and columns are resized by click-dragging,
and I'm guessing this is how we want it to work in Scribus too?
Something that comes to mind is that for most items Scribus uses a
modal way of interacting with the item: In the "normal" mode, the user
is able to select, move and resize an item, while in the "editing"
mode (entered by double-clicking) he/she is able to perform editing
actions on the item, such as inserting text in text frames, or moving
vertices of a polygon. Is this modal way of working something we want
for tables as well, in order for them to fit in with the Scribus way
of working? If so, I'm guessing actions such as column/row resizing
should be available in the "editing" mode, while in the "normal" mode
the user is only able to move/resize the table?

=== Styles ===
A while ago I took an afternoon and investigated what it takes to
create a new kind of style in Scribus, thinking this is something we
might want for tables. It was mostly straight forward and I ended up
with a primitive skeleton of a new style which is now in my Git repo.
Since then however, I've started thinking; Are styles for tables (and
even for rows/columns/cells) something we really want, or are they an
unnecessary complication for small benefits? I don't know about other
programs, but Indesign does not have named styles for tables. Tables
are simply formatted by direct editing of properties for individual
tables. How common are use cases where the user would really be
hampered without support for named table (and possibly
cell/row/column) styles? Would it be sufficient for Scribus if editing
table properties is a per-table operation? I'd really like to get the
opinion of other team members on this.

=== Cell Selection ===
I'm guessing we want cell selection to work similar to word processors
and Indesign, where a user is able to enter a "cell selection" mode by
starting to select some text in a cell with the mouse and then
dragging outside the cell boundaries?

== Technical Questions ==
Below are some of the technical questions I have to find answers to.
Since the content of table cells will be represented using Scribus'
regular text frames, several of the questions below are related to
this.

=== Notification of Text Overflow in Text Frames ===
Using text frames for cell content means the table will have to be
notified when overflow occurs in a text frame, to be able to correctly
re-layout the table starting from the row in which the overflow
occurred. If we eventually want to have width-growing columns, we'll
also need a way to be notified when a line break is about to occur in
a text frame. So the question is; do text frames currently emit any
signals to indicate that content is overflowing? It seems they are
not, but one place where such a signal could possibly be emitted is in
PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might
not be a correct solution though, perhaps the table should instead
listen to insertions being made in the text frame, and query the frame
for its overflow state using PageItem::frameOverflows()?

In addition to being notified of when overflow happens, the table will
also need to be able to query the text frame for the height of its
content, to be able to resize it correctly during table layout. Is
this possible using the current API? If not, what would it take to add
it?

=== Editing of Cell Content ===
As the text frames have their own modal way of being edited, and on
top of that we'll probably have a modal way of editing tables (see
above under Interaction Questions), how will we combine the two when
it comes to editing cell content? I really don't think we want a
multi-layered modal interaction, where the user first has to
double-click the table, and then again double-click a cell in order to
edit its content. Indesign is on the other extreme of this, there a
user can directly edit the content of a table, without any modes of
operation. I think what we want in Scribus is for the user to
immediately be able to interact with the content of cells after the
first double-click on the table. Or what do you think?

On top of this is the question of keyboard navigation between cells,
which I'm sure we want. The table will probably have to somehow filter
the keyboard events before they hit the underlying text frame of the
cell in order to get this to work.

=== Disabling Decorations / Resize Handles of Text Frames ===
I will have to figure out how drawing of decorations, and possibly
also the resize handles of text frames can be disabled. The table will
only be interested in the text displaying / editing capabilities of
the text frames, and will not want them to draw anything else such as
borders, decorations or resize handles. Perhaps this is an easy thing,
but still something I'll have to investigate.

_______________________________________________
scribus-dev mailing list
scribus-dev at lists.scribus.net
http://lists.scribus.net/mailman/listinfo/scribus-dev


From elvstone at gmail.com  Sun May 15 18:02:02 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Sun, 15 May 2011 20:02:02 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <D23D6B9E57D654429A9AB6918CACEAA98060741F69@NAMBX02.corp.adobe.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<D23D6B9E57D654429A9AB6918CACEAA98060741F69@NAMBX02.corp.adobe.com>
Message-ID: <BANLkTi=afuQh-x4fRf9U6T8z=MrJRzJh1A@mail.gmail.com>

Hello Leonard, and thanks for your prompt reply.

2011/5/15 Leonard Rosenthol <lrosenth at adobe.com>:
> Some comments/corrections on Tables and InDesign.
>
>>Something that might be different from how tables
>>will work in Scribus is that in Indesign, tables can only exist as
>>inline objects inside a text frame, not as objects on their own.
>>
> That's because by having them as part of a text frame, you can then have other things wrap around them and they act "inline". ?Having a "table frame" doesn't really fit the model that most users are used to - it also makes it more complex to implement when you start thinking inline. ?It also helps with selects that cross the table boundary (eg. Some text and some table).

Right. I'm aware of the concept of inline vs. non-inline of course.
However, in Scribus text can flow around objects that are not inline.
You're right about "acting" inline though, that won't be possible with
the "tables as a PageItem" approach, unless Scribus has some general
support for making any PageItem inline, and I don't think it has. Can
anyone enlighten me here? What's the state of support for inline
objects, is there any support at all?

>
>
>>Another thing which I think
>>will naturally be different in Scribus is that in Scribus, editing of
>>item properties is mostly done through the Properties palette, and not
>>so much through dialogs that pop up (thankfully! because table editing
>>in Indesign seems to be very dialog-intense).
>>
> This is where your inexperience with InDesign shows :). ?If you look closely, you will see that it's properties bar enables full control w/o ever seeing a single dialog. ?And if you don't like the bar, you can also show the Table Palette (floating or docked) and change things there too...

Guilty as charged :) I only got it installed yesterday and obviously I
haven't played around with it enough, but missing both the Table
Palette and the fact that there's actually styles for both tables and
cells was quite bad on my part.

>
>
>>In Indesign, tables, rows and columns are resized by click-dragging,
>>and I'm guessing this is how we want it to work in Scribus too?
>>
> You can also type explicit values into the properties bar or palette.

Yes, and I expect something similar is wanted in Scribus too.

>
>
>>In Indesign, tables, rows and columns are resized by click-dragging,
>>and I'm guessing this is how we want it to work in Scribus too?
>>
> Not only does InDesign have named styles for an entire table, we also have Cell styles for individual cells (or groups of them, such as Rows or Columns).

Yes, don't know how I missed those.

>
>
>>In Indesign, tables, rows and columns are resized by click-dragging,
>>and I'm guessing this is how we want it to work in Scribus too?
>>
> Don't forget individual row and column selection as well.

Right.

>
>
>>Using text frames for cell content
>>
> While this is one of the most common first pass methods for how to do tables - you may (will) find that it doesn't work well when you wish to enable cross-cell and cross-table selection and manipulation.

This is indeed a valid concern, and one I'll have to think long and hard about.

>
>
> Hope that helps....

Yes, again, thanks a lot for the quick reply.

So.. In light of Leonards response here. Do we still think that tables
as page items is the way forward? Because I thought that had been
pretty much agreed on. My idea was that the tables would initially be
made as page items that could only be placed freely on the page, not
inline in text frames, and that later on, Scribus text layout engine
could possibly be given the ability to place items such as tables
inline (with modifications to tables to support working in this new
setting). Now I'm not so sure anymore, and I'd really like it if more
of you could answer.

Regards,
Elvis

>
> Leonard
>
> -----Original Message-----
> From: Elvis Stansvik [mailto:elvstone at gmail.com]
> Sent: Sunday, May 15, 2011 9:58 AM
> To: Scribus Development Mailing List
> Subject: [scribus-dev] Preparations for GSoC
>
> Hello Scribus folks,
>
> Summer is getting closer fast, and while I'm exceedingly busy with
> preparations for my upcoming exams, I think it's important I get at
> least some preparations for GSoC done so that I can get a flying start
> and have a clear direction for my project once May 28 comes and exams
> are over. I've started to write down some preliminary questions and
> thoughts around my project and put them on the wiki [1], but I'll
> include that page almost verbatim below, sans some of the wiki markup,
> so that we can discuss it on-list. The wiki has a couple of
> screenshots from Indesign, so perhaps you'll still want to check that
> out. I'll extend/update the page as my project progresses.
>
> I would be very grateful if you could read through these questions
> once and give your comments. I'm especially interested in things where
> you feel "no no no, not like that", or if there are things where you
> know things will get hairy technically. I think it's important we're
> on the same page regarding how the tables should work in Scribus from
> the get-go, so any and all input is relevant.
>
> Lastly, in the midst of everything I believe I've never asked who will
> be my mentor this summer, might be good to know :) Malex? MrB?
>
> Best regards,
> Elvis
>
> [1] http://wiki.scribus.net/canvas/GSoC_2011_Tables
>
> = GSoC 2011 Tables =
> This page contains technical and functionality related considerations
> regarding the implementation of tables in Scribus as part of Google
> Summer of Code 2011. Here I'll try to keep an up to date document
> describing the design of the implementation, a list of open technical
> problems and questions regarding the functionality of the tables,
> including a couple of use cases as well as everything else concerning
> my work on bringing tables support to Scribus.
>
> == General Design ==
> As was outlined briefly in my project proposal, the tables in Scribus
> will be implemented as a new page item. Handling of cell content will
> be delegated to text frames.
>
> == Interaction Questions ==
> In the questions below, I refer quite a lot to Adobe Indesign. This is
> not because I see it as a template of good design or anything, it's
> just that I happen to have come across a copy of it which I have
> running under VirtualBox, and it helps to have something existing to
> discuss around.
>
> === Table Creation/Editing ===
> Is there a general consensus on how we want interaction with the
> tables to work? Looking at how tables work in Indesign CS5.5, their
> design is quite straight forward and works essentially as those found
> in word processors: The user is presented with a "Table" menu from
> which tables can be inserted and manipulated and formatted through
> dialogs that pop up. Something that might be different from how tables
> will work in Scribus is that in Indesign, tables can only exist as
> inline objects inside a text frame, not as objects on their own.
>
> I'm imagining that in Scribus, the user is able to freely position the
> tables on the page, while in the future, we can hopefully let the user
> insert the table item I'll be creating inline in running text by
> making it an inline object of some kind? Another thing which I think
> will naturally be different in Scribus is that in Scribus, editing of
> item properties is mostly done through the Properties palette, and not
> so much through dialogs that pop up (thankfully! because table editing
> in Indesign seems to be very dialog-intense). I guess we will have a
> new tab on the PP called "Table" that will be disabled unless a table
> is selected, similar to how it works for images?
>
> === Table/Row/Column Resizing ===
> In Indesign, tables, rows and columns are resized by click-dragging,
> and I'm guessing this is how we want it to work in Scribus too?
> Something that comes to mind is that for most items Scribus uses a
> modal way of interacting with the item: In the "normal" mode, the user
> is able to select, move and resize an item, while in the "editing"
> mode (entered by double-clicking) he/she is able to perform editing
> actions on the item, such as inserting text in text frames, or moving
> vertices of a polygon. Is this modal way of working something we want
> for tables as well, in order for them to fit in with the Scribus way
> of working? If so, I'm guessing actions such as column/row resizing
> should be available in the "editing" mode, while in the "normal" mode
> the user is only able to move/resize the table?
>
> === Styles ===
> A while ago I took an afternoon and investigated what it takes to
> create a new kind of style in Scribus, thinking this is something we
> might want for tables. It was mostly straight forward and I ended up
> with a primitive skeleton of a new style which is now in my Git repo.
> Since then however, I've started thinking; Are styles for tables (and
> even for rows/columns/cells) something we really want, or are they an
> unnecessary complication for small benefits? I don't know about other
> programs, but Indesign does not have named styles for tables. Tables
> are simply formatted by direct editing of properties for individual
> tables. How common are use cases where the user would really be
> hampered without support for named table (and possibly
> cell/row/column) styles? Would it be sufficient for Scribus if editing
> table properties is a per-table operation? I'd really like to get the
> opinion of other team members on this.
>
> === Cell Selection ===
> I'm guessing we want cell selection to work similar to word processors
> and Indesign, where a user is able to enter a "cell selection" mode by
> starting to select some text in a cell with the mouse and then
> dragging outside the cell boundaries?
>
> == Technical Questions ==
> Below are some of the technical questions I have to find answers to.
> Since the content of table cells will be represented using Scribus'
> regular text frames, several of the questions below are related to
> this.
>
> === Notification of Text Overflow in Text Frames ===
> Using text frames for cell content means the table will have to be
> notified when overflow occurs in a text frame, to be able to correctly
> re-layout the table starting from the row in which the overflow
> occurred. If we eventually want to have width-growing columns, we'll
> also need a way to be notified when a line break is about to occur in
> a text frame. So the question is; do text frames currently emit any
> signals to indicate that content is overflowing? It seems they are
> not, but one place where such a signal could possibly be emitted is in
> PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might
> not be a correct solution though, perhaps the table should instead
> listen to insertions being made in the text frame, and query the frame
> for its overflow state using PageItem::frameOverflows()?
>
> In addition to being notified of when overflow happens, the table will
> also need to be able to query the text frame for the height of its
> content, to be able to resize it correctly during table layout. Is
> this possible using the current API? If not, what would it take to add
> it?
>
> === Editing of Cell Content ===
> As the text frames have their own modal way of being edited, and on
> top of that we'll probably have a modal way of editing tables (see
> above under Interaction Questions), how will we combine the two when
> it comes to editing cell content? I really don't think we want a
> multi-layered modal interaction, where the user first has to
> double-click the table, and then again double-click a cell in order to
> edit its content. Indesign is on the other extreme of this, there a
> user can directly edit the content of a table, without any modes of
> operation. I think what we want in Scribus is for the user to
> immediately be able to interact with the content of cells after the
> first double-click on the table. Or what do you think?
>
> On top of this is the question of keyboard navigation between cells,
> which I'm sure we want. The table will probably have to somehow filter
> the keyboard events before they hit the underlying text frame of the
> cell in order to get this to work.
>
> === Disabling Decorations / Resize Handles of Text Frames ===
> I will have to figure out how drawing of decorations, and possibly
> also the resize handles of text frames can be disabled. The table will
> only be interested in the text displaying / editing capabilities of
> the text frames, and will not want them to draw anything else such as
> borders, decorations or resize handles. Perhaps this is an easy thing,
> but still something I'll have to investigate.
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From cbradney at zip.com.au  Sun May 15 20:10:57 2011
From: cbradney at zip.com.au (Craig Bradney)
Date: Sun, 15 May 2011 22:10:57 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTi=afuQh-x4fRf9U6T8z=MrJRzJh1A@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<D23D6B9E57D654429A9AB6918CACEAA98060741F69@NAMBX02.corp.adobe.com>
	<BANLkTi=afuQh-x4fRf9U6T8z=MrJRzJh1A@mail.gmail.com>
Message-ID: <4DD03351.1050301@zip.com.au>


> Yes, again, thanks a lot for the quick reply.
>
> So.. In light of Leonards response here. Do we still think that tables
> as page items is the way forward? Because I thought that had been
> pretty much agreed on. My idea was that the tables would initially be
> made as page items that could only be placed freely on the page, not
> inline in text frames, and that later on, Scribus text layout engine
> could possibly be given the ability to place items such as tables
> inline (with modifications to tables to support working in this new
> setting). Now I'm not so sure anymore, and I'd really like it if more
> of you could answer.

Scribus can handle (within the boundaries of the implementation.. which
is average, needs lots of work) inline items within a text frame.. its
not robust enough to handle its current job though.

However, I still think tables as pageitems is a valid approach,
certainly in the scope and time frame of GSoC, with the idea of
replacing the current pageitems. Having a fully functional pageitem
implementation would be a million times better than what we have, and I
don't see the primary functionality needing to change whether it be in a
page item or inline.

Craig


From ale.comp_06 at xox.ch  Mon May 16 11:11:14 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Mon, 16 May 2011 13:11:14 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
Message-ID: <4DD10652.9090801@xox.ch>

hi elvis,

nice to see you preparing your work!



> Lastly, in the midst of everything I believe I've never asked who will
> be my mentor this summer, might be good to know :) Malex? MrB?

melange says: mrb (craig)

> == General Design ==
> As was outlined briefly in my project proposal, the tables in Scribus
> will be implemented as a new page item. Handling of cell content will
> be delegated to text frames.

i tend to prefere this approach to the inline items we've heard of...

> Another thing which I think
> will naturally be different in Scribus is that in Scribus, editing of
> item properties is mostly done through the Properties palette, and not
> so much through dialogs that pop up (thankfully! because table editing
> in Indesign seems to be very dialog-intense). I guess we will have a
> new tab on the PP called "Table" that will be disabled unless a table
> is selected, similar to how it works for images?

the PP will  lose its tabs and will become content sensitive... but it 
does not change much to the fact that it's probably a good idea to 
implement the table settings as a PP tab.

> tables, rows and columns are resized by click-dragging,
> and I'm guessing this is how we want it to work in Scribus too?

click and dragging + exact measurement in the PP

> Something that comes to mind is that for most items Scribus uses a
> modal way of interacting with the item: In the "normal" mode, the user
> is able to select, move and resize an item, while in the "editing"
> mode (entered by double-clicking) he/she is able to perform editing
> actions on the item, such as inserting text in text frames, or moving
> vertices of a polygon. Is this modal way of working something we want
> for tables as well, in order for them to fit in with the Scribus way
> of working? If so, I'm guessing actions such as column/row resizing
> should be available in the "editing" mode, while in the "normal" mode
> the user is only able to move/resize the table?
probably, yes, we should keep the modal way of working.

there were some discussion on changing this behavior for text and image 
frames, and the result was that it's not a bad idea to keep the current 
state (it can help prevent accidental change; on the other side 
manipulation can be a bit slower...)
in my eyes, the most important thing is, that the program behaves in a 
consistent way: if we want cells to be "always" resizable, we should 
plan also to change the behavior for text and image frames.


> === Styles ===
> A while ago I took an afternoon and investigated what it takes to
> create a new kind of style in Scribus, thinking this is something we
> might want for tables. It was mostly straight forward and I ended up
> with a primitive skeleton of a new style which is now in my Git repo.
> Since then however, I've started thinking; Are styles for tables (and
> even for rows/columns/cells) something we really want, or are they an
> unnecessary complication for small benefits?
basically, i think that we would like to get styles for as many things 
as possible. frame styles are (somehow) already planned...


> I'm guessing we want cell selection to work similar to word processors
> and Indesign, where a user is able to enter a "cell selection" mode by
> starting to select some text in a cell with the mouse and then
> dragging outside the cell boundaries?

in scribus you go to the "normal" mode to edit the container... i guess 
we should keep this behavior...
the question is how to best select the elements... i tend to like the 
current alt-click, but we should better document how to get the window 
managers not to capture the alt-clicks.

> === Notification of Text Overflow in Text Frames ===
> Using text frames for cell content means the table will have to be
> notified when overflow occurs in a text frame, to be able to correctly
> re-layout the table starting from the row in which the overflow
> occurred. If we eventually want to have width-growing columns, we'll
> also need a way to be notified when a line break is about to occur in
> a text frame. So the question is; do text frames currently emit any
> signals to indicate that content is overflowing? It seems they are
> not, but one place where such a signal could possibly be emitted is in
> PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might
> not be a correct solution though, perhaps the table should instead
> listen to insertions being made in the text frame, and query the frame
> for its overflow state using PageItem::frameOverflows()?
do we want the cells to automatically grow?
in scribus, nothing automatically grows...

text overflow can be queried from the scripter, you can go there to find 
out how to do it :-)

> In addition to being notified of when overflow happens, the table will
> also need to be able to query the text frame for the height of its
> content, to be able to resize it correctly during table layout. Is
> this possible using the current API? If not, what would it take to add
> it?

it's not done and i'm not 100% it's a good idea to implement it...
it will certainly be helpful for newcomers (but what will they think 
when the page is filled and there is no place for growing the frame? 
should we automatically create a new page? ask for it? ... not sure it's 
a good idea...)

> === Editing of Cell Content ===
> As the text frames have their own modal way of being edited, and on
> top of that we'll probably have a modal way of editing tables (see
> above under Interaction Questions), how will we combine the two when
> it comes to editing cell content? I really don't think we want a
> multi-layered modal interaction, where the user first has to
> double-click the table, and then again double-click a cell in order to
> edit its content.

double clicking a cell should start the edit mode.

the question is how to find the context in the modal editing... imo we 
could have both in the PP (table / cell)

> On top of this is the question of keyboard navigation between cells,
> which I'm sure we want. The table will probably have to somehow filter
> the keyboard events before they hit the underlying text frame of the
> cell in order to get this to work.

(shift) tab should be captured and used as next cell...
not sure if we want other navigation keys...

> === Disabling Decorations / Resize Handles of Text Frames ===
> I will have to figure out how drawing of decorations, and possibly
> also the resize handles of text frames can be disabled. The table will
> only be interested in the text displaying / editing capabilities of
> the text frames, and will not want them to draw anything else such as
> borders, decorations or resize handles. Perhaps this is an easy thing,
> but still something I'll have to investigate.

i think that it should work in the same way as for text frames...


hope that helps... :-)

keep up the good work!

ciao
a.l.e


From elvstone at gmail.com  Mon May 16 12:08:52 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Mon, 16 May 2011 14:08:52 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <4DD10652.9090801@xox.ch>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
Message-ID: <BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>

Hi a.l.e,

2011/5/16 a.l.e <ale.comp_06 at xox.ch>:
> hi elvis,
>
> nice to see you preparing your work!
>
>
>
>> Lastly, in the midst of everything I believe I've never asked who will
>> be my mentor this summer, might be good to know :) Malex? MrB?
>
> melange says: mrb (craig)

Ah, thanks. I never seem to be able to work the melange site
correctly. Seems each year it sucks in new ways, though this year it's
not as bad as it was in 2009.

>
>> == General Design ==
>> As was outlined briefly in my project proposal, the tables in Scribus
>> will be implemented as a new page item. Handling of cell content will
>> be delegated to text frames.
>
> i tend to prefere this approach to the inline items we've heard of...

Yes, from an implementation point of view I think it will be simpler,
though inline tables is for sure a valid use case. But hopefully we
can work that out later. And as Craig said, there's nothing about the
basic functionality of the tables that should have to change in inline
vs. non-inline mode.

>
>> Another thing which I think
>> will naturally be different in Scribus is that in Scribus, editing of
>> item properties is mostly done through the Properties palette, and not
>> so much through dialogs that pop up (thankfully! because table editing
>> in Indesign seems to be very dialog-intense). I guess we will have a
>> new tab on the PP called "Table" that will be disabled unless a table
>> is selected, similar to how it works for images?
>
> the PP will ?lose its tabs and will become content sensitive... but it does
> not change much to the fact that it's probably a good idea to implement the
> table settings as a PP tab.

Alright, good to know about these plans though.

>
>> tables, rows and columns are resized by click-dragging,
>> and I'm guessing this is how we want it to work in Scribus too?
>
> click and dragging + exact measurement in the PP

Like I imagined it too.

>
>> Something that comes to mind is that for most items Scribus uses a
>> modal way of interacting with the item: In the "normal" mode, the user
>> is able to select, move and resize an item, while in the "editing"
>> mode (entered by double-clicking) he/she is able to perform editing
>> actions on the item, such as inserting text in text frames, or moving
>> vertices of a polygon. Is this modal way of working something we want
>> for tables as well, in order for them to fit in with the Scribus way
>> of working? If so, I'm guessing actions such as column/row resizing
>> should be available in the "editing" mode, while in the "normal" mode
>> the user is only able to move/resize the table?
>
> probably, yes, we should keep the modal way of working.
>
> there were some discussion on changing this behavior for text and image
> frames, and the result was that it's not a bad idea to keep the current
> state (it can help prevent accidental change; on the other side manipulation
> can be a bit slower...)
> in my eyes, the most important thing is, that the program behaves in a
> consistent way: if we want cells to be "always" resizable, we should plan
> also to change the behavior for text and image frames.

Yes, consistency is worthwhile, and why I brought it up. I also think
tables should have an editing mode in which operations such as
resizing/adding/removing of rows/columns is performed. I don't know if
I explained my concern over multiple layers of modality good enough
though, but more about that further down.

>
>
>> === Styles ===
>> A while ago I took an afternoon and investigated what it takes to
>> create a new kind of style in Scribus, thinking this is something we
>> might want for tables. It was mostly straight forward and I ended up
>> with a primitive skeleton of a new style which is now in my Git repo.
>> Since then however, I've started thinking; Are styles for tables (and
>> even for rows/columns/cells) something we really want, or are they an
>> unnecessary complication for small benefits?
>
> basically, i think that we would like to get styles for as many things as
> possible. frame styles are (somehow) already planned...

Yes, and after my slightly embarrassing ignorance of the fact that
InDesign actually has a quite comprehensive support for table and cell
styles in my initial post (corrected by Leonard above) I must agree,
and will make sure Scribus supports this too.

>
>
>> I'm guessing we want cell selection to work similar to word processors
>> and Indesign, where a user is able to enter a "cell selection" mode by
>> starting to select some text in a cell with the mouse and then
>> dragging outside the cell boundaries?
>
> in scribus you go to the "normal" mode to edit the container... i guess we
> should keep this behavior...

Yes, but this is where my concern over multiple layers of modality
come in. Do I understand you correctly that you actually want one
three modes of operation:

1) Normal Mode: The user is able to select, move and resize the table.
2) Table Editing Mode: The user is able to insert/remove/resize rows
and columns.
3) Cell Editing Mode: The users is able to edit cell content.

And if so, in which mode, 2 or 3, will the user be able to select a
rectangular region of cells by mouse-dragging? As you probably know,
in word processors and in InDesign, doing this is a matter of starting
to select a span of text in a cell and then going outside the cell,
which will enter a cell selection mode where a region of cells is
selected. This would be equivalent to cell selections being done in
mode 3 above (the innermost mode). The alternative is letting the user
do this in mode 2. With that approach, individual cells would then be
directly selectable by just clicking them, and a region of cells by
click-dragging.

In addition to selection of individual cells and rectangular region of
cells, we need selection of rows and columns, and I guess this will
work in mode 2 just like it does in word processors, the mouse cursor
will be changed to an arrow pointing right when hovering the left edge
of a row, and an arrow pointing down when hovering the top edge of a
column. Upon click the entire row or column will be selected,
respectively.

Or maybe you had something else in mind than these three modes of operation?

> the question is how to best select the elements... i tend to like the
> current alt-click, but we should better document how to get the window
> managers not to capture the alt-clicks.

Ah, now I see what you mean. I was honestly not aware of the Alt
modifier to select items inside a group (is it used for something else
as well?), as I'm so used to having Alt for moving windows.

Perhaps in addition to the cell selection behavior I explained above,
we could allow the user to, while in the normal mode (mode 1), select
individual cells by Alt-clicking. But I'm pretty sure that somewhere
we need to give the user the ability to select a rectangular region of
cells.

>
>> === Notification of Text Overflow in Text Frames ===
>> Using text frames for cell content means the table will have to be
>> notified when overflow occurs in a text frame, to be able to correctly
>> re-layout the table starting from the row in which the overflow
>> occurred. If we eventually want to have width-growing columns, we'll
>> also need a way to be notified when a line break is about to occur in
>> a text frame. So the question is; do text frames currently emit any
>> signals to indicate that content is overflowing? It seems they are
>> not, but one place where such a signal could possibly be emitted is in
>> PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might
>> not be a correct solution though, perhaps the table should instead
>> listen to insertions being made in the text frame, and query the frame
>> for its overflow state using PageItem::frameOverflows()?
>
> do we want the cells to automatically grow?
> in scribus, nothing automatically grows...

Well I've just assumed that we want this as it's how almost every
other table I've ever seen works, but indeed, nothing automatically
grows in Scribus. Naturally non-growing behavior should be supported
even if auto-growing is implemented. But what do you other guys think?
Grow or not?

>
> text overflow can be queried from the scripter, you can go there to find out
> how to do it :-)

Good tip. After writing my initial mail and that wiki page, I realized
that some of what I said was non-sensical, as I was suggesting to emit
signals for this inside the decoration drawing method of PageItem,
which doesn't make sense. Listening to text insertions and then
querying the item for overflow is probably the way to go.

>
>> In addition to being notified of when overflow happens, the table will
>> also need to be able to query the text frame for the height of its
>> content, to be able to resize it correctly during table layout. Is
>> this possible using the current API? If not, what would it take to add
>> it?
>
> it's not done and i'm not 100% it's a good idea to implement it...
> it will certainly be helpful for newcomers (but what will they think when
> the page is filled and there is no place for growing the frame? should we
> automatically create a new page? ask for it? ... not sure it's a good
> idea...)

Hm yes. I guess it would just grow and the user would realize that his
table doesn't fit the page and cope with it. But I see your point.

If you really don't want rows and tables to automatically grow, you've
cut a good chunk out of the table layout logic out of my work :)
Again, what do you other guys think? MrB?

>
>> === Editing of Cell Content ===
>> As the text frames have their own modal way of being edited, and on
>> top of that we'll probably have a modal way of editing tables (see
>> above under Interaction Questions), how will we combine the two when
>> it comes to editing cell content? I really don't think we want a
>> multi-layered modal interaction, where the user first has to
>> double-click the table, and then again double-click a cell in order to
>> edit its content.
>
> double clicking a cell should start the edit mode.

Okay, but related to my questions regarding the 3 modes above. Is that
what you want, or should cells be directly editable by double-clicking
in normal mode, cutting the number of modes down to 2? It's very good
that we work this out now before I start!

>
> the question is how to find the context in the modal editing... imo we could
> have both in the PP (table / cell)

Yes, I think so too. Having both table and cell properties up when
inside a cell makes sense.

This context sensitive PP you talk of, has it been made public yet?
Will it be merged to my GSoC git repo?

>
>> On top of this is the question of keyboard navigation between cells,
>> which I'm sure we want. The table will probably have to somehow filter
>> the keyboard events before they hit the underlying text frame of the
>> cell in order to get this to work.
>
> (shift) tab should be captured and used as next cell...
> not sure if we want other navigation keys...

Alright. Possible other ways of navigation can be figured out later.

>
>> === Disabling Decorations / Resize Handles of Text Frames ===
>> I will have to figure out how drawing of decorations, and possibly
>> also the resize handles of text frames can be disabled. The table will
>> only be interested in the text displaying / editing capabilities of
>> the text frames, and will not want them to draw anything else such as
>> borders, decorations or resize handles. Perhaps this is an easy thing,
>> but still something I'll have to investigate.
>
> i think that it should work in the same way as for text frames...

Hm. You mean the handles of the text frames being used for cell
content should be visible when a cell is selected? I would have
thought that the table wants to draw any cell selection decoration and
handles itself, to have full control over how they look. Do you also
think they should be visible for all the cells in a selected region of
cells. Will that not look cluttered?

And for cell borders, I'm not 100% sure yet if we can re-use the
border support of the text frames, or if the table will have to do the
painting of cell borders itself. I'll look into this. It will depend
on what border model we want to have i think; the CSS collapsing
border model, or something else. I'll also take a look at what border
model InDesign is using.

>
>
> hope that helps... :-)

It most certainly does. Thanks a lot for the input.

Elvis

>
> keep up the good work!
>
> ciao
> a.l.e
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From andreas.vox at googlemail.com  Mon May 16 23:01:09 2011
From: andreas.vox at googlemail.com (Andreas Vox)
Date: Tue, 17 May 2011 01:01:09 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
Message-ID: <B9DC7A11-B39B-4116-A433-B32564139459@googlemail.com>


Am 16.05.2011 um 14:08 schrieb Elvis Stansvik:

> Hi a.l.e,
> 
> 2011/5/16 a.l.e <ale.comp_06 at xox.ch>:
> ...

>> 
>>> Something that comes to mind is that for most items Scribus uses a
>>> modal way of interacting with the item: In the "normal" mode, the user
>>> is able to select, move and resize an item, while in the "editing"
>>> mode (entered by double-clicking) he/she is able to perform editing
>>> actions on the item, such as inserting text in text frames, or moving
>>> vertices of a polygon. Is this modal way of working something we want
>>> for tables as well, in order for them to fit in with the Scribus way
>>> of working? If so, I'm guessing actions such as column/row resizing
>>> should be available in the "editing" mode, while in the "normal" mode
>>> the user is only able to move/resize the table?
>> 
>> probably, yes, we should keep the modal way of working.
>> 
>> there were some discussion on changing this behavior for text and image
>> frames, and the result was that it's not a bad idea to keep the current
>> state (it can help prevent accidental change; on the other side manipulation
>> can be a bit slower...)
>> in my eyes, the most important thing is, that the program behaves in a
>> consistent way: if we want cells to be "always" resizable, we should plan
>> also to change the behavior for text and image frames.
> 
> Yes, consistency is worthwhile, and why I brought it up. I also think
> tables should have an editing mode in which operations such as
> resizing/adding/removing of rows/columns is performed. I don't know if
> I explained my concern over multiple layers of modality good enough
> though, but more about that further down.
> 
>> 
>> 
>>> === Styles ===
>>> A while ago I took an afternoon and investigated what it takes to
>>> create a new kind of style in Scribus, thinking this is something we
>>> might want for tables. It was mostly straight forward and I ended up
>>> with a primitive skeleton of a new style which is now in my Git repo.
>>> Since then however, I've started thinking; Are styles for tables (and
>>> even for rows/columns/cells) something we really want, or are they an
>>> unnecessary complication for small benefits?
>> 
>> basically, i think that we would like to get styles for as many things as
>> possible. frame styles are (somehow) already planned...
> 
 +1

> Yes, and after my slightly embarrassing ignorance of the fact that
> InDesign actually has a quite comprehensive support for table and cell
> styles in my initial post (corrected by Leonard above) I must agree,
> and will make sure Scribus supports this too.
> 
>> 
>> 
>>> I'm guessing we want cell selection to work similar to word processors
>>> and Indesign, where a user is able to enter a "cell selection" mode by
>>> starting to select some text in a cell with the mouse and then
>>> dragging outside the cell boundaries?
>> 
>> in scribus you go to the "normal" mode to edit the container... i guess we
>> should keep this behavior...
> 
> Yes, but this is where my concern over multiple layers of modality
> come in. Do I understand you correctly that you actually want one
> three modes of operation:
> 
> 1) Normal Mode: The user is able to select, move and resize the table.
> 2) Table Editing Mode: The user is able to insert/remove/resize rows
> and columns.
> 3) Cell Editing Mode: The users is able to edit cell content.
> 
> And if so, in which mode, 2 or 3, will the user be able to select a
> rectangular region of cells by mouse-dragging? As you probably know,
> in word processors and in InDesign, doing this is a matter of starting
> to select a span of text in a cell and then going outside the cell,
> which will enter a cell selection mode where a region of cells is
> selected. This would be equivalent to cell selections being done in
> mode 3 above (the innermost mode). The alternative is letting the user
> do this in mode 2. With that approach, individual cells would then be
> directly selectable by just clicking them, and a region of cells by
> click-dragging.
> 
> In addition to selection of individual cells and rectangular region of
> cells, we need selection of rows and columns, and I guess this will
> work in mode 2 just like it does in word processors, the mouse cursor
> will be changed to an arrow pointing right when hovering the left edge
> of a row, and an arrow pointing down when hovering the top edge of a
> column. Upon click the entire row or column will be selected,
> respectively.
> 
> Or maybe you had something else in mind than these three modes of operation?
> 

I'd prefer only two modes of operation: normal/selection + editing text

We can add extra controls to table items which allow row/column resizing and selection. Same with context menus and shortcuts.

>> the question is how to best select the elements... i tend to like the
>> current alt-click, but we should better document how to get the window
>> managers not to capture the alt-clicks.
> 
> Ah, now I see what you mean. I was honestly not aware of the Alt
> modifier to select items inside a group (is it used for something else
> as well?), as I'm so used to having Alt for moving windows.
> 
> Perhaps in addition to the cell selection behavior I explained above,
> we could allow the user to, while in the normal mode (mode 1), select
> individual cells by Alt-clicking. But I'm pretty sure that somewhere
> we need to give the user the ability to select a rectangular region of
> cells.
> 
>> 
>>> === Notification of Text Overflow in Text Frames ===
>>> Using text frames for cell content means the table will have to be
>>> notified when overflow occurs in a text frame, to be able to correctly
>>> re-layout the table starting from the row in which the overflow
>>> occurred. If we eventually want to have width-growing columns, we'll
>>> also need a way to be notified when a line break is about to occur in
>>> a text frame. So the question is; do text frames currently emit any
>>> signals to indicate that content is overflowing? It seems they are
>>> not, but one place where such a signal could possibly be emitted is in
>>> PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might
>>> not be a correct solution though, perhaps the table should instead
>>> listen to insertions being made in the text frame, and query the frame
>>> for its overflow state using PageItem::frameOverflows()?
>> 
>> do we want the cells to automatically grow?
>> in scribus, nothing automatically grows...
> 
> Well I've just assumed that we want this as it's how almost every
> other table I've ever seen works, but indeed, nothing automatically
> grows in Scribus. Naturally non-growing behavior should be supported
> even if auto-growing is implemented. But what do you other guys think?
> Grow or not?


My opinion: only grow/shrink cell height, but don't do that to cell width. 
That way you can just use a text frame of the given cell width and ask for its needed height. That's much easier than figuring out the needed width (especially with multiline cells).

Shrinking frame height to text height should be added to normal text frames as an option anyway (maybe as a vertical align option?)

> 
>> 
>> text overflow can be queried from the scripter, you can go there to find out
>> how to do it :-)
> 
> Good tip. After writing my initial mail and that wiki page, I realized
> that some of what I said was non-sensical, as I was suggesting to emit
> signals for this inside the decoration drawing method of PageItem,
> which doesn't make sense. Listening to text insertions and then
> querying the item for overflow is probably the way to go.
> 
>> 
>>> In addition to being notified of when overflow happens, the table will
>>> also need to be able to query the text frame for the height of its
>>> content, to be able to resize it correctly during table layout. Is
>>> this possible using the current API? If not, what would it take to add
>>> it?
>> 
>> it's not done and i'm not 100% it's a good idea to implement it...
>> it will certainly be helpful for newcomers (but what will they think when
>> the page is filled and there is no place for growing the frame? should we
>> automatically create a new page? ask for it? ... not sure it's a good
>> idea...)
> 
> Hm yes. I guess it would just grow and the user would realize that his
> table doesn't fit the page and cope with it. But I see your point.
> 
> If you really don't want rows and tables to automatically grow, you've
> cut a good chunk out of the table layout logic out of my work :)
> Again, what do you other guys think? MrB?
> 
>> 
>>> === Editing of Cell Content ===
>>> As the text frames have their own modal way of being edited, and on
>>> top of that we'll probably have a modal way of editing tables (see
>>> above under Interaction Questions), how will we combine the two when
>>> it comes to editing cell content? I really don't think we want a
>>> multi-layered modal interaction, where the user first has to
>>> double-click the table, and then again double-click a cell in order to
>>> edit its content.
>> 
>> double clicking a cell should start the edit mode.
> 
> Okay, but related to my questions regarding the 3 modes above. Is that
> what you want, or should cells be directly editable by double-clicking
> in normal mode, cutting the number of modes down to 2? It's very good
> that we work this out now before I start!
> 
>> 
>> the question is how to find the context in the modal editing... imo we could
>> have both in the PP (table / cell)
> 
> Yes, I think so too. Having both table and cell properties up when
> inside a cell makes sense.
> 
> This context sensitive PP you talk of, has it been made public yet?
> Will it be merged to my GSoC git repo?
> 
>> 
>>> On top of this is the question of keyboard navigation between cells,
>>> which I'm sure we want. The table will probably have to somehow filter
>>> the keyboard events before they hit the underlying text frame of the
>>> cell in order to get this to work.
>> 
>> (shift) tab should be captured and used as next cell...
>> not sure if we want other navigation keys...
> 
> Alright. Possible other ways of navigation can be figured out later.
> 
>> 
>>> === Disabling Decorations / Resize Handles of Text Frames ===
>>> I will have to figure out how drawing of decorations, and possibly
>>> also the resize handles of text frames can be disabled. The table will
>>> only be interested in the text displaying / editing capabilities of
>>> the text frames, and will not want them to draw anything else such as
>>> borders, decorations or resize handles. Perhaps this is an easy thing,
>>> but still something I'll have to investigate.
>> 
>> i think that it should work in the same way as for text frames...
> 
> Hm. You mean the handles of the text frames being used for cell
> content should be visible when a cell is selected? I would have
> thought that the table wants to draw any cell selection decoration and
> handles itself, to have full control over how they look. Do you also
> think they should be visible for all the cells in a selected region of
> cells. Will that not look cluttered?
> 
> And for cell borders, I'm not 100% sure yet if we can re-use the
> border support of the text frames, or if the table will have to do the
> painting of cell borders itself. I'll look into this. It will depend
> on what border model we want to have i think; the CSS collapsing
> border model, or something else. I'll also take a look at what border
> model InDesign is using.
> 

I wouldn't use the borders of text frames. Cell borders are more complex.

The controls of a text frame are drawn by the current canvas mode. For table frames I would expect different controls to be drawn to allow resizing of rows/columns.

In edit mode I'd expect the margins/tab ruler to be displayed just for the current cell.


/Andreas

>> 
>> 
>> hope that helps... :-)
> 
> It most certainly does. Thanks a lot for the input.
> 
> Elvis
> 
>> 
>> keep up the good work!
>> 
>> ciao
>> a.l.e
>> 
>> _______________________________________________
>> scribus-dev mailing list
>> scribus-dev at lists.scribus.net
>> http://lists.scribus.net/mailman/listinfo/scribus-dev
>> 
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110517/193c7a99/attachment-0001.html>

From elvstone at gmail.com  Tue May 17 11:06:31 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 13:06:31 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <B9DC7A11-B39B-4116-A433-B32564139459@googlemail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<B9DC7A11-B39B-4116-A433-B32564139459@googlemail.com>
Message-ID: <BANLkTim8nc6DwkvtkWB-ufX4jO67UjX1hA@mail.gmail.com>

Hi Andreas,

2011/5/17 Andreas Vox <andreas.vox at googlemail.com>:
>
> ...
>
> I'd prefer only two modes of operation: normal/selection + editing text
> We can add extra controls to table items which allow row/column resizing and
> selection. Same with context menus and shortcuts.

Right, I tend to agree. Three different modes of editing is cumbersome.

But to clarify, do you mean it should be possible to manipulate these
controls for e.g. row height and column width in normal mode or only
after entering cell text editing mode?

>
> ...
>
> My opinion: only grow/shrink cell height, but don't do that to cell width.
> That way you can just use a text frame of the given cell width and ask for
> its needed height. That's much easier than figuring out the needed width
> (especially with multiline cells).

Yes, width growing tables is a pretty obscure feature, and I only
brought it up as a side note since it's a feature of e.g. ODF tables.
But again, it is obscure, and as you say, trickier to implement than
height growing. In fact, it's only now, two years after my 2009 GSoC,
that Casper in Calligra is starting to add support for it to Calligra.

But back to height growing. It seems a.l.e. is hesitant whether we
want this at all, seeing as nothing currently grows automatically in
Scribus.

> Shrinking frame height to text height should be added to normal text frames
> as an option anyway (maybe as a vertical align option?)

Are you talking about a manual option to shrink the text frame to the
height of the text it is currently holding, or about text frames that
automatically grows/shrinks as text is entered/deleted in the frame?
Is this an officially planned feature?

And does anyone else want to chime in on this? Should I aim to make
tables that will automatically grow vertically to fit content or not?
If I do, there'll naturally be support for turning off this behavior,
or the default could be off.

Would be nice to hear what MrB thinks too, as he's my mentor after all ;)

>
> ...
>
> I wouldn't use the borders of text frames. Cell borders are more complex.

Yes, unless we want the table borders to be really primitive, the
tables will need to take care of this themselves, so I agree.

> The controls of a text frame are drawn by the current canvas mode. For table
> frames I would expect different controls to be drawn to allow resizing of
> rows/columns.

That's sounds like how I imagined it to be done.

> In edit mode I'd expect the margins/tab ruler to be displayed just for the
> current cell.

Yes.

Last night I sat down and made a "dummy" table item and pushed it to
my repo, just to see how easy/hard adding a new type of item to
Scribus is. It was quite straightforward. The item can be inserted
exactly the same way as the current table implementation, and it
currently just shows the text "I am a table". Baby steps ;)

Anyway, thanks for the input Andreas!

MrB, would love to hear what you have to say on some of these questions.

Regards,
Elvis

>
> /Andreas
>
>
> hope that helps... :-)
>
> It most certainly does. Thanks a lot for the input.
>
> Elvis
>
>
> keep up the good work!
>
> ciao
>
> a.l.e
>
> _______________________________________________
>
> scribus-dev mailing list
>
> scribus-dev at lists.scribus.net
>
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>


From elvstone at gmail.com  Tue May 17 11:20:36 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 13:20:36 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTim8nc6DwkvtkWB-ufX4jO67UjX1hA@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<B9DC7A11-B39B-4116-A433-B32564139459@googlemail.com>
	<BANLkTim8nc6DwkvtkWB-ufX4jO67UjX1hA@mail.gmail.com>
Message-ID: <BANLkTikULoZawPDgkFfEYSCSJLg9VN_2ag@mail.gmail.com>

2011/5/17 Elvis Stansvik <elvstone at gmail.com>:
> ...
>
> Last night I sat down and made a "dummy" table item and pushed it to
> my repo, just to see how easy/hard adding a new type of item to
> Scribus is.
>

Oh and I should add that while doing so, clumsy me managed to bork the
commit message, it currently reads

"Add a dummy table item

The item just draws the text "I am a table". The mode used when drag-
existing "table" implementation."

which is quite non-sensical. It was supposed to be

"Add a dummy table item

The item just draws the text "I am a table". The mode used when drag-
creating the item is called modeDrawTable2, as to not conflict with the
current tables implementation.".

I guess I must have done something wrong when commiting from inside Qt
Creator, which I'm trying to get used to. I'm usually a Vim junkie,
but trying Qt Creator out as it's quite convenient when working on a
large unknown code base.

I tried to fix up the commit message with git commit --amend and then
git push --force, but SF git server does not allow such forced commits
unless you explicitly enable it. So I'll just leave it at that and try
to not be as clumsy in the future ;)

Elvis


From cbradney at scribus.info  Tue May 17 11:22:50 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Tue, 17 May 2011 13:22:50 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTim8nc6DwkvtkWB-ufX4jO67UjX1hA@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<B9DC7A11-B39B-4116-A433-B32564139459@googlemail.com>
	<BANLkTim8nc6DwkvtkWB-ufX4jO67UjX1hA@mail.gmail.com>
Message-ID: <74BB03AF-69F8-456F-97CC-96B990A3C998@scribus.info>





On 17/05/2011, at 13:06, Elvis Stansvik <elvstone at gmail.com> wrote:

> Hi Andreas,
> 
> 2011/5/17 Andreas Vox <andreas.vox at googlemail.com>:
>> 
>> ...
>> 
>> I'd prefer only two modes of operation: normal/selection + editing text
>> We can add extra controls to table items which allow row/column resizing and
>> selection. Same with context menus and shortcuts.
> 
> Right, I tend to agree. Three different modes of editing is cumbersome.
> 
> But to clarify, do you mean it should be possible to manipulate these
> controls for e.g. row height and column width in normal mode or only
> after entering cell text editing mode?
> 
>> 
>> ...
>> 
>> My opinion: only grow/shrink cell height, but don't do that to cell width.
>> That way you can just use a text frame of the given cell width and ask for
>> its needed height. That's much easier than figuring out the needed width
>> (especially with multiline cells).
> 
> Yes, width growing tables is a pretty obscure feature, and I only
> brought it up as a side note since it's a feature of e.g. ODF tables.
> But again, it is obscure, and as you say, trickier to implement than
> height growing. In fact, it's only now, two years after my 2009 GSoC,
> that Casper in Calligra is starting to add support for it to Calligra.
> 
> But back to height growing. It seems a.l.e. is hesitant whether we
> want this at all, seeing as nothing currently grows automatically in
> Scribus.
> 
>> Shrinking frame height to text height should be added to normal text frames
>> as an option anyway (maybe as a vertical align option?)
> 
> Are you talking about a manual option to shrink the text frame to the
> height of the text it is currently holding, or about text frames that
> automatically grows/shrinks as text is entered/deleted in the frame?
> Is this an officially planned feature?
> 
> And does anyone else want to chime in on this? Should I aim to make
> tables that will automatically grow vertically to fit content or not?
> If I do, there'll naturally be support for turning off this behavior,
> or the default could be off.
> 
> Would be nice to hear what MrB thinks too, as he's my mentor after all ;)
> 
>> 
>> ...
>> 
>> I wouldn't use the borders of text frames. Cell borders are more complex.
> 
> Yes, unless we want the table borders to be really primitive, the
> tables will need to take care of this themselves, so I agree.
> 
>> The controls of a text frame are drawn by the current canvas mode. For table
>> frames I would expect different controls to be drawn to allow resizing of
>> rows/columns.
> 
> That's sounds like how I imagined it to be done.
> 
>> In edit mode I'd expect the margins/tab ruler to be displayed just for the
>> current cell.
> 
> Yes.
> 
> Last night I sat down and made a "dummy" table item and pushed it to
> my repo, just to see how easy/hard adding a new type of item to
> Scribus is. It was quite straightforward. The item can be inserted
> exactly the same way as the current table implementation, and it
> currently just shows the text "I am a table". Baby steps ;)
> 
> Anyway, thanks for the input Andreas!
> 
> MrB, would love to hear what you have to say on some of these questions.
> 
> Regards,
> Elvis

I'll be able to answer tonight via mail...

Thanks, the conversation is leading to the right answers I think

Craig

From elvstone at gmail.com  Tue May 17 11:31:44 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 13:31:44 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <74BB03AF-69F8-456F-97CC-96B990A3C998@scribus.info>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<B9DC7A11-B39B-4116-A433-B32564139459@googlemail.com>
	<BANLkTim8nc6DwkvtkWB-ufX4jO67UjX1hA@mail.gmail.com>
	<74BB03AF-69F8-456F-97CC-96B990A3C998@scribus.info>
Message-ID: <BANLkTikSf_8f_-Qc9EoKtoXT=UXYuJtkkg@mail.gmail.com>

Hi Craig,

2011/5/17 Craig Bradney <cbradney at scribus.info>:
> ...
>
> I'll be able to answer tonight via mail...

Great. No hurry at all.

> Thanks, the conversation is leading to the right answers I think

Good. I think so too.

Elvis


From ale.comp_06 at xox.ch  Tue May 17 11:34:14 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Tue, 17 May 2011 13:34:14 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
Message-ID: <4DD25D36.2000608@xox.ch>

hi elvis,

>> == General Design ==
>> As was outlined briefly in my project proposal, the tables in Scribus
>> will be implemented as a new page item. Handling of cell content will
>> be delegated to text frames.
>> i tend to prefere this approach to the inline items we've heard of...
> Yes, from an implementation point of view I think it will be simpler,
> though inline tables is for sure a valid use case. But hopefully we
> can work that out later. And as Craig said, there's nothing about the
> basic functionality of the tables that should have to change in inline
> vs. non-inline mode.

we should be able to copy paste any type of item into a text frame and 
use it as an inline object...

so, defining tables as "real" items just opens up new chances :-)
(and i hope that most people will want to create tables as real items!)



>>> Another thing which I think
>>> will naturally be different in Scribus is that in Scribus, editing of
>>> item properties is mostly done through the Properties palette, and not
>>> so much through dialogs that pop up (thankfully! because table editing
>>> in Indesign seems to be very dialog-intense). I guess we will have a
>>> new tab on the PP called "Table" that will be disabled unless a table
>>> is selected, similar to how it works for images?
>> the PP will  lose its tabs and will become content sensitive... but it does
>> not change much to the fact that it's probably a good idea to implement the
>> table settings as a PP tab.
> Alright, good to know about these plans though.

this is the best you can currently read about the scribus-oif project:

http://ospublish.constantvzw.org/news/scribus-re-loaded

a part of the PP redesign is to get it as a single panel window (but 
split in frame and content properties)

part of it is already in 1.5svn. part of it is in the 1.5 oif branch

>
>>
>>> I'm guessing we want cell selection to work similar to word processors
>>> and Indesign, where a user is able to enter a "cell selection" mode by
>>> starting to select some text in a cell with the mouse and then
>>> dragging outside the cell boundaries?
>> in scribus you go to the "normal" mode to edit the container... i guess we
>> should keep this behavior...
> Yes, but this is where my concern over multiple layers of modality
> come in. Do I understand you correctly that you actually want one
> three modes of operation:
>
> 1) Normal Mode: The user is able to select, move and resize the table.
> 2) Table Editing Mode: The user is able to insert/remove/resize rows
> and columns.
> 3) Cell Editing Mode: The users is able to edit cell content.
>
> And if so, in which mode, 2 or 3, will the user be able to select a
> rectangular region of cells by mouse-dragging? As you probably know,
> in word processors and in InDesign, doing this is a matter of starting
> to select a span of text in a cell and then going outside the cell,
> which will enter a cell selection mode where a region of cells is
> selected. This would be equivalent to cell selections being done in
> mode 3 above (the innermost mode). The alternative is letting the user
> do this in mode 2. With that approach, individual cells would then be
> directly selectable by just clicking them, and a region of cells by
> click-dragging.
>
> In addition to selection of individual cells and rectangular region of
> cells, we need selection of rows and columns, and I guess this will
> work in mode 2 just like it does in word processors, the mouse cursor
> will be changed to an arrow pointing right when hovering the left edge
> of a row, and an arrow pointing down when hovering the top edge of a
> column. Upon click the entire row or column will be selected,
> respectively.
>
> Or maybe you had something else in mind than these three modes of operation?

in my mind 1 and 2 were mostly merged... but i didn't spend much to make 
my mind :-)

>> the question is how to best select the elements... i tend to like the
>> current alt-click, but we should better document how to get the window
>> managers not to capture the alt-clicks.
> Ah, now I see what you mean. I was honestly not aware of the Alt
> modifier to select items inside a group (is it used for something else
> as well?), as I'm so used to having Alt for moving windows.

alt for moving windows should be deprecated!
the window key is much better for it.

you have to switch them also for inkscape...

> Perhaps in addition to the cell selection behavior I explained above,
> we could allow the user to, while in the normal mode (mode 1), select
> individual cells by Alt-clicking. But I'm pretty sure that somewhere
> we need to give the user the ability to select a rectangular region of
> cells.

alt+shift and alt+ctrl?


>>> === Notification of Text Overflow in Text Frames ===
>>> Using text frames for cell content means the table will have to be
>>> notified when overflow occurs in a text frame, to be able to correctly
>>> re-layout the table starting from the row in which the overflow
>>> occurred. If we eventually want to have width-growing columns, we'll
>>> also need a way to be notified when a line break is about to occur in
>>> a text frame. So the question is; do text frames currently emit any
>>> signals to indicate that content is overflowing? It seems they are
>>> not, but one place where such a signal could possibly be emitted is in
>>> PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might
>>> not be a correct solution though, perhaps the table should instead
>>> listen to insertions being made in the text frame, and query the frame
>>> for its overflow state using PageItem::frameOverflows()?
>> do we want the cells to automatically grow?
>> in scribus, nothing automatically grows...
> Well I've just assumed that we want this as it's how almost every
> other table I've ever seen works, but indeed, nothing automatically
> grows in Scribus. Naturally non-growing behavior should be supported
> even if auto-growing is implemented. But what do you other guys think?
> Grow or not?

me? not grow.

if somebody wants autogrowing tables, he should do them in oo/lo and 
then have a way to import in a native scribus table.

just like he's dong with text.

DTP is about control... or not?


>>> === Editing of Cell Content ===
>>> As the text frames have their own modal way of being edited, and on
>>> top of that we'll probably have a modal way of editing tables (see
>>> above under Interaction Questions), how will we combine the two when
>>> it comes to editing cell content? I really don't think we want a
>>> multi-layered modal interaction, where the user first has to
>>> double-click the table, and then again double-click a cell in order to
>>> edit its content.
>> double clicking a cell should start the edit mode.
> Okay, but related to my questions regarding the 3 modes above. Is that
> what you want, or should cells be directly editable by double-clicking
> in normal mode, cutting the number of modes down to 2? It's very good
> that we work this out now before I start!

if we can find a way to edit all the properties with only two modes, i'd 
prefere that.

>> the question is how to find the context in the modal editing... imo we could
>> have both in the PP (table / cell)
> Yes, I think so too. Having both table and cell properties up when
> inside a cell makes sense.
>
> This context sensitive PP you talk of, has it been made public yet?
> Will it be merged to my GSoC git repo?

jean ghali is working onn it

the idea is public, but not much publicity has been made about it, yet 
(beside of the talk by jean and pierre last week at the lgm... which 
will be online at some time in the future...)


ciao
a.l.e

p.s.: i wrote this post yesterday... but then got some distractions...



From elvstone at gmail.com  Tue May 17 11:53:38 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 13:53:38 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <4DD25D36.2000608@xox.ch>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
Message-ID: <BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>

2011/5/17 a.l.e <ale.comp_06 at xox.ch>:
> hi elvis,
>
>>> == General Design ==
>>> As was outlined briefly in my project proposal, the tables in Scribus
>>> will be implemented as a new page item. Handling of cell content will
>>> be delegated to text frames.
>>> i tend to prefere this approach to the inline items we've heard of...
>>
>> Yes, from an implementation point of view I think it will be simpler,
>> though inline tables is for sure a valid use case. But hopefully we
>> can work that out later. And as Craig said, there's nothing about the
>> basic functionality of the tables that should have to change in inline
>> vs. non-inline mode.
>
> we should be able to copy paste any type of item into a text frame and use
> it as an inline object...

Yes, that would be the best. I suspect that is quite a non-trivial
task though. And text selections across both text and inline items
containing items, such as nested text frames and tables, will also be
quite hairy. But that's for the future then.

>
> so, defining tables as "real" items just opens up new chances :-)
> (and i hope that most people will want to create tables as real items!)

Good.

>>>> Another thing which I think
>>>> will naturally be different in Scribus is that in Scribus, editing of
>>>> item properties is mostly done through the Properties palette, and not
>>>> so much through dialogs that pop up (thankfully! because table editing
>>>> in Indesign seems to be very dialog-intense). I guess we will have a
>>>> new tab on the PP called "Table" that will be disabled unless a table
>>>> is selected, similar to how it works for images?
>>>
>>> the PP will ?lose its tabs and will become content sensitive... but it
>>> does
>>> not change much to the fact that it's probably a good idea to implement
>>> the
>>> table settings as a PP tab.
>>
>> Alright, good to know about these plans though.
>
> this is the best you can currently read about the scribus-oif project:
>
> http://ospublish.constantvzw.org/news/scribus-re-loaded

Yep, I believe I've read that news item once. Exciting stuff.

>
> a part of the PP redesign is to get it as a single panel window (but split
> in frame and content properties)

Sounds good.

> part of it is already in 1.5svn. part of it is in the 1.5 oif branch

Okay. Do you think this is something that is going to be finished
during the course of the summer, or is it further into the future? I'm
just thinking, if it's just around the corner, I should hold off those
UI parts of my project until it has landed in it's entirety. But
perhaps it will be a trivial refactor and I shouldn't worry.

> ...
>
> in my mind 1 and 2 were mostly merged... but i didn't spend much to make my
> mind :-)

Yes, I think we all seem to be mostly on the same page now; 2 modes.
The details can be hopefully be worked out as the project progresses.

> ...
>
> alt for moving windows should be deprecated!
> the window key is much better for it.

That's true I guess ;) And I have no problem with switching to Meta for that.

>
> you have to switch them also for inkscape...

Right.

> ...
>
> me? not grow.
>
> if somebody wants autogrowing tables, he should do them in oo/lo and then
> have a way to import in a native scribus table.
>
> just like he's dong with text.
>
> DTP is about control... or not?

Okay, so a bit of conflicting minds about this. Perhaps I could skip
the growing for an initial version, and if I add them later on make it
an optional feature. I'll await Craig's opinion on this tonight too.

> ...
>
> if we can find a way to edit all the properties with only two modes, i'd
> prefere that.

Yes, me too.

>
>>> the question is how to find the context in the modal editing... imo we
>>> could
>>> have both in the PP (table / cell)
>>
>> Yes, I think so too. Having both table and cell properties up when
>> inside a cell makes sense.
>>
>> This context sensitive PP you talk of, has it been made public yet?
>> Will it be merged to my GSoC git repo?
>
> jean ghali is working onn it
>
> the idea is public, but not much publicity has been made about it, yet
> (beside of the talk by jean and pierre last week at the lgm... which will be
> online at some time in the future...)

Okay.

Regards,
Elvis


From elvstone at gmail.com  Tue May 17 11:56:56 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 13:56:56 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
Message-ID: <BANLkTi=QpLz9Pv3xTiJjYN7jV1BOdGrCmQ@mail.gmail.com>

2011/5/17 Elvis Stansvik <elvstone at gmail.com>:
> ...
>
> Yes, that would be the best. I suspect that is quite a non-trivial
> task though. And text selections across both text and inline items
> containing items, such as nested text frames and tables, will also be
> quite hairy. But that's for the future then.
>

Err I mean "and inline items containing text".

Elvis


From ale.comp_06 at xox.ch  Tue May 17 12:00:02 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Tue, 17 May 2011 14:00:02 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<4DD10652.9090801@xox.ch>	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
Message-ID: <4DD26342.5000804@xox.ch>

hi

>> part of it is already in 1.5svn. part of it is in the 1.5 oif branch
> Okay. Do you think this is something that is going to be finished
> during the course of the summer, or is it further into the future? I'm
> just thinking, if it's just around the corner, I should hold off those
> UI parts of my project until it has landed in it's entirety. But
> perhaps it will be a trivial refactor and I shouldn't worry.

jean?

what's your thoughts about it?

ciao
a.l.e


From gpittman at iglou.com  Tue May 17 12:25:54 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Tue, 17 May 2011 08:25:54 -0400
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<4DD10652.9090801@xox.ch>	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
Message-ID: <4DD26952.20904@iglou.com>

On 05/17/2011 07:53 AM, Elvis Stansvik wrote:
>
> Okay, so a bit of conflicting minds about this. Perhaps I could skip
> the growing for an initial version, and if I add them later on make it
> an optional feature. I'll await Craig's opinion on this tonight too.
>

I think we have to consider one of the kinds of feedback we have gotten 
from users who want better, more flexible tables. They want to be able 
to easily import contents from some kind of database. Some talk about 
very large datasets, like catalogues and such. A table might be larger 
than a single page, so what would happen then? Can a table be broken 
into sub-tables spreading over multiple pages? What happens when you add 
a new row in the middle -- can a subsequent row be bumped to the next 
page? And for that matter, if automatic growing of cells doesn't happen, 
then surely editing will cause a table to overlap to the next page.

All of this would not have to be implemented now, but the basic 
structure of the table needs to accommodate these features to be added 
later.

I don't think that relying on making tables in a outside app and 
importing gets us any farther than we are now. If we are going to accept 
that, then we can expect that the day will come when LibreOffice 
develops enough DTP/PDF capabilities that users will skip Scribus 
altogether.

Greg


From elvstone at gmail.com  Tue May 17 13:01:20 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 15:01:20 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <4DD26952.20904@iglou.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
Message-ID: <BANLkTim+JZ3p+QsfWXFsJwQ91sam=dv58g@mail.gmail.com>

Hello Gregory,

2011/5/17 Gregory Pittman <gpittman at iglou.com>:
> On 05/17/2011 07:53 AM, Elvis Stansvik wrote:
>>
>> Okay, so a bit of conflicting minds about this. Perhaps I could skip
>> the growing for an initial version, and if I add them later on make it
>> an optional feature. I'll await Craig's opinion on this tonight too.
>>
>
> I think we have to consider one of the kinds of feedback we have gotten from
> users who want better, more flexible tables. They want to be able to easily
> import contents from some kind of database. Some talk about very large
> datasets, like catalogues and such. A table might be larger than a single
> page, so what would happen then? Can a table be broken into sub-tables
> spreading over multiple pages? What happens when you add a new row in the
> middle -- can a subsequent row be bumped to the next page? And for that
> matter, if automatic growing of cells doesn't happen, then surely editing
> will cause a table to overlap to the next page.

Breaking tables across pages is indeed a non-trivial problem, and was
taken out of my GSoC project during the review of my project proposal,
partly for that reason (see [1]). However, I will of course keep in
mind that this is a desirable feature in the future. Although it might
not be implemented this summer, I'm open to discuss how this problem
could be solved in the future. I expect it to be quite tricky, but
doable.

Regarding importing of big data sets. That I agree is probably a
common use case. I also agree that table rows not growing in height
during importing of large tables would probably be a bad idea and very
frustrating for the user. It's good that you bring this up. Perhaps as
a stop-gap measure, until proper dynamic breaking of tables across
pages is implemented, the table import function could statically break
the single table into multiple smaller ones that will each fit on a
page.

I'm not quite sure I understand your last sentence though, could you
clarify? If automatic growing is not happening, why would that imply
tables overlapping to the next page?

>
> All of this would not have to be implemented now, but the basic structure of
> the table needs to accommodate these features to be added later.

Right. So that needs to be kept in mind.

>
> I don't think that relying on making tables in a outside app and importing
> gets us any farther than we are now. If we are going to accept that, then we
> can expect that the day will come when LibreOffice develops enough DTP/PDF
> capabilities that users will skip Scribus altogether.

I agree that would feel like a defeat. Even though the tables I'll be
writing this summer won't be full-featured, my hope is of course that
one day they will be able to rival those of e.g. InDesign. And that
means it's important to at least keep advanced features like these in
mind early on.

Thanks,
Elvis


From elvstone at gmail.com  Tue May 17 13:02:01 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 15:02:01 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTim+JZ3p+QsfWXFsJwQ91sam=dv58g@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<BANLkTim+JZ3p+QsfWXFsJwQ91sam=dv58g@mail.gmail.com>
Message-ID: <BANLkTikB-eCNaDwrd+YP7JxmDOVJHcgRwg@mail.gmail.com>

2011/5/17 Elvis Stansvik <elvstone at gmail.com>:
> Hello Gregory,
>
> 2011/5/17 Gregory Pittman <gpittman at iglou.com>:
>> On 05/17/2011 07:53 AM, Elvis Stansvik wrote:
>>>
>>> Okay, so a bit of conflicting minds about this. Perhaps I could skip
>>> the growing for an initial version, and if I add them later on make it
>>> an optional feature. I'll await Craig's opinion on this tonight too.
>>>
>>
>> I think we have to consider one of the kinds of feedback we have gotten from
>> users who want better, more flexible tables. They want to be able to easily
>> import contents from some kind of database. Some talk about very large
>> datasets, like catalogues and such. A table might be larger than a single
>> page, so what would happen then? Can a table be broken into sub-tables
>> spreading over multiple pages? What happens when you add a new row in the
>> middle -- can a subsequent row be bumped to the next page? And for that
>> matter, if automatic growing of cells doesn't happen, then surely editing
>> will cause a table to overlap to the next page.
>
> Breaking tables across pages is indeed a non-trivial problem, and was
> taken out of my GSoC project during the review of my project proposal,
> partly for that reason (see [1]). However, I will of course keep in

Forgot footnote:

[1] http://lists.scribus.net/pipermail/scribus-dev/2011-March/000871.html

Elvis


From andreas.vox at googlemail.com  Tue May 17 16:42:53 2011
From: andreas.vox at googlemail.com (Andreas Vox)
Date: Tue, 17 May 2011 18:42:53 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <4DD26952.20904@iglou.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<4DD10652.9090801@xox.ch>	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
Message-ID: <78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>


Am 17.05.2011 um 14:25 schrieb Gregory Pittman:

> On 05/17/2011 07:53 AM, Elvis Stansvik wrote:
>> 
>> Okay, so a bit of conflicting minds about this. Perhaps I could skip
>> the growing for an initial version, and if I add them later on make it
>> an optional feature. I'll await Craig's opinion on this tonight too.
>> 
> 
> I think we have to consider one of the kinds of feedback we have gotten from users who want better, more flexible tables. They want to be able to easily import contents from some kind of database. Some talk about very large datasets, like catalogues and such. A table might be larger than a single page, so what would happen then? Can a table be broken into sub-tables spreading over multiple pages? What happens when you add a new row in the middle -- can a subsequent row be bumped to the next page? And for that matter, if automatic growing of cells doesn't happen, then surely editing will cause a table to overlap to the next page.
> 
> All of this would not have to be implemented now, but the basic structure of the table needs to accommodate these features to be added later.
> 
> I don't think that relying on making tables in a outside app and importing gets us any farther than we are now. If we are going to accept that, then we can expect that the day will come when LibreOffice develops enough DTP/PDF capabilities that users will skip Scribus altogether.

That's an important use case. I think cells (rows) need to grow automatically, otherwise editing will just be a pita. The other question is, what should happen if the existing rows don't fit into the table frame anymore: a) grow the table frame or b) cut the rest of the rows off and display an overflow marker. b) would be consistent with current text frames but would need a way how to flow the extra rows into another table frame.

All-in-all I think b) would be more professional. Maybe just implement that with manual linking of table frames and save automatic linking and repeating headers/footers for after GSoC?

/Andreas

From elvstone at gmail.com  Tue May 17 17:29:28 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 19:29:28 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
Message-ID: <BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>

2011/5/17 Andreas Vox <andreas.vox at googlemail.com>:
>
> Am 17.05.2011 um 14:25 schrieb Gregory Pittman:
>
>> On 05/17/2011 07:53 AM, Elvis Stansvik wrote:
>>>
>>> Okay, so a bit of conflicting minds about this. Perhaps I could skip
>>> the growing for an initial version, and if I add them later on make it
>>> an optional feature. I'll await Craig's opinion on this tonight too.
>>>
>>
>> I think we have to consider one of the kinds of feedback we have gotten from users who want better, more flexible tables. They want to be able to easily import contents from some kind of database. Some talk about very large datasets, like catalogues and such. A table might be larger than a single page, so what would happen then? Can a table be broken into sub-tables spreading over multiple pages? What happens when you add a new row in the middle -- can a subsequent row be bumped to the next page? And for that matter, if automatic growing of cells doesn't happen, then surely editing will cause a table to overlap to the next page.
>>
>> All of this would not have to be implemented now, but the basic structure of the table needs to accommodate these features to be added later.
>>
>> I don't think that relying on making tables in a outside app and importing gets us any farther than we are now. If we are going to accept that, then we can expect that the day will come when LibreOffice develops enough DTP/PDF capabilities that users will skip Scribus altogether.
>
> That's an important use case. I think cells (rows) need to grow automatically, otherwise editing will just be a pita. The other question is, what should happen if the existing rows don't fit into the table frame anymore: a) grow the table frame or b) cut the rest of the rows off and display an overflow marker. b) would be consistent with current text frames but would need a way how to flow the extra rows into another table frame.

Hold on! ;) "Rows don't fit into the table frame"? You're talking
about "table frames" here, which I'm not sure what they are. I didn't
think the tables themselves would be frames, just items. I knew I was
going to use the existing text frames for the content of cells, but
thought that tables would just be items, not necessarily frames. So
you mean that tables should somehow be contained inside a frame? A
frame which can be resized independently without affecting the size or
layout of the table it is containing? Won't that be clumsy to use?

I imagined that if you resize a table, you're either scaling the all
the cells inside it, or you're actually changing the width of the last
column and the height of the last row (two ways of doing it). This is
similar to how it works in InDesign. But you're thinking of some
surrounding frame for the table, detached from normal table layout?

I must get this straight, because frankly I'm a little confused now :)

Elvis

>
> All-in-all I think b) would be more professional. Maybe just implement that with manual linking of table frames and save automatic linking and repeating headers/footers for after GSoC?
>
> /Andreas
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From andreas.vox at googlemail.com  Tue May 17 18:12:00 2011
From: andreas.vox at googlemail.com (Andreas Vox)
Date: Tue, 17 May 2011 20:12:00 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
Message-ID: <C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>


Am 17.05.2011 um 19:29 schrieb Elvis Stansvik:

> 2011/5/17 Andreas Vox <andreas.vox at googlemail.com>:
>> 
>> Am 17.05.2011 um 14:25 schrieb Gregory Pittman:
>> 
>>> On 05/17/2011 07:53 AM, Elvis Stansvik wrote:
>>>> 
>>>> Okay, so a bit of conflicting minds about this. Perhaps I could skip
>>>> the growing for an initial version, and if I add them later on make it
>>>> an optional feature. I'll await Craig's opinion on this tonight too.
>>>> 
>>> 
>>> I think we have to consider one of the kinds of feedback we have gotten from users who want better, more flexible tables. They want to be able to easily import contents from some kind of database. Some talk about very large datasets, like catalogues and such. A table might be larger than a single page, so what would happen then? Can a table be broken into sub-tables spreading over multiple pages? What happens when you add a new row in the middle -- can a subsequent row be bumped to the next page? And for that matter, if automatic growing of cells doesn't happen, then surely editing will cause a table to overlap to the next page.
>>> 
>>> All of this would not have to be implemented now, but the basic structure of the table needs to accommodate these features to be added later.
>>> 
>>> I don't think that relying on making tables in a outside app and importing gets us any farther than we are now. If we are going to accept that, then we can expect that the day will come when LibreOffice develops enough DTP/PDF capabilities that users will skip Scribus altogether.
>> 
>> That's an important use case. I think cells (rows) need to grow automatically, otherwise editing will just be a pita. The other question is, what should happen if the existing rows don't fit into the table frame anymore: a) grow the table frame or b) cut the rest of the rows off and display an overflow marker. b) would be consistent with current text frames but would need a way how to flow the extra rows into another table frame.
> 
> Hold on! ;) "Rows don't fit into the table frame"? You're talking
> about "table frames" here, which I'm not sure what they are. I didn't
> think the tables themselves would be frames, just items. I knew I was
> going to use the existing text frames for the content of cells, but
> thought that tables would just be items, not necessarily frames. So
> you mean that tables should somehow be contained inside a frame? A
> frame which can be resized independently without affecting the size or
> layout of the table it is containing? Won't that be clumsy to use?
> 
> I imagined that if you resize a table, you're either scaling the all
> the cells inside it, or you're actually changing the width of the last
> column and the height of the last row (two ways of doing it). This is
> similar to how it works in InDesign. But you're thinking of some
> surrounding frame for the table, detached from normal table layout?
> 
> I must get this straight, because frankly I'm a little confused now :)

I use item and frame interchangeably. Where is the difference to you?

My idea is simply that table rows in table items should behave like text lines in text items.
So you would display as many rows as fit and then drop the rest and display an overflow marker.

Then a linked table item would be told the first row to display and so on.

/Andreas

From gpittman at iglou.com  Tue May 17 18:47:50 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Tue, 17 May 2011 14:47:50 -0400
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTim+JZ3p+QsfWXFsJwQ91sam=dv58g@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<4DD10652.9090801@xox.ch>	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>	<4DD25D36.2000608@xox.ch>	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>	<4DD26952.20904@iglou.com>
	<BANLkTim+JZ3p+QsfWXFsJwQ91sam=dv58g@mail.gmail.com>
Message-ID: <4DD2C2D6.10702@iglou.com>

On 05/17/2011 09:01 AM, Elvis Stansvik wrote:
> Hello Gregory,
>
> 2011/5/17 Gregory Pittman<gpittman at iglou.com>:

>> spreading over multiple pages? What happens when you add a new row in the
>> middle -- can a subsequent row be bumped to the next page? And for that
>> matter, if automatic growing of cells doesn't happen, then surely editing
>> will cause a table to overlap to the next page.
>
>
> I'm not quite sure I understand your last sentence though, could you
> clarify? If automatic growing is not happening, why would that imply
> tables overlapping to the next page?

If we make growing a manual operation only (and even with automatic, 
manual editing of cell size will still need to happen), I may have a 
table that fits nicely on a page, but then I put in an image of a 
certain size or add text to a cell which causes the table to now be too big.

If rows or columns can be separated (think of a table on a two-page 
spread), then perhaps using features of Align and Distribute to align 
the broken off parts to margin(s), guide(s), or other features would be 
a good working mode.

Greg


From elvstone at gmail.com  Tue May 17 19:48:33 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 21:48:33 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
Message-ID: <BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>

2011/5/17 Andreas Vox <andreas.vox at googlemail.com>:
>
> Am 17.05.2011 um 19:29 schrieb Elvis Stansvik:
>
>> 2011/5/17 Andreas Vox <andreas.vox at googlemail.com>:
>>>
>>> Am 17.05.2011 um 14:25 schrieb Gregory Pittman:
>>>
>>>> On 05/17/2011 07:53 AM, Elvis Stansvik wrote:
>>>>>
>>>>> Okay, so a bit of conflicting minds about this. Perhaps I could skip
>>>>> the growing for an initial version, and if I add them later on make it
>>>>> an optional feature. I'll await Craig's opinion on this tonight too.
>>>>>
>>>>
>>>> I think we have to consider one of the kinds of feedback we have gotten from users who want better, more flexible tables. They want to be able to easily import contents from some kind of database. Some talk about very large datasets, like catalogues and such. A table might be larger than a single page, so what would happen then? Can a table be broken into sub-tables spreading over multiple pages? What happens when you add a new row in the middle -- can a subsequent row be bumped to the next page? And for that matter, if automatic growing of cells doesn't happen, then surely editing will cause a table to overlap to the next page.
>>>>
>>>> All of this would not have to be implemented now, but the basic structure of the table needs to accommodate these features to be added later.
>>>>
>>>> I don't think that relying on making tables in a outside app and importing gets us any farther than we are now. If we are going to accept that, then we can expect that the day will come when LibreOffice develops enough DTP/PDF capabilities that users will skip Scribus altogether.
>>>
>>> That's an important use case. I think cells (rows) need to grow automatically, otherwise editing will just be a pita. The other question is, what should happen if the existing rows don't fit into the table frame anymore: a) grow the table frame or b) cut the rest of the rows off and display an overflow marker. b) would be consistent with current text frames but would need a way how to flow the extra rows into another table frame.
>>
>> Hold on! ;) "Rows don't fit into the table frame"? You're talking
>> about "table frames" here, which I'm not sure what they are. I didn't
>> think the tables themselves would be frames, just items. I knew I was
>> going to use the existing text frames for the content of cells, but
>> thought that tables would just be items, not necessarily frames. So
>> you mean that tables should somehow be contained inside a frame? A
>> frame which can be resized independently without affecting the size or
>> layout of the table it is containing? Won't that be clumsy to use?
>>
>> I imagined that if you resize a table, you're either scaling the all
>> the cells inside it, or you're actually changing the width of the last
>> column and the height of the last row (two ways of doing it). This is
>> similar to how it works in InDesign. But you're thinking of some
>> surrounding frame for the table, detached from normal table layout?
>>
>> I must get this straight, because frankly I'm a little confused now :)
>
> I use item and frame interchangeably. Where is the difference to you?

No difference I guess. It's just that the way you described it made me
jump a little because that's not how I had imagined it. But I think
you're actually on to a good idea on how table breaking across pages
could be implemented, in a way that would feel native to Scribus. I
like the analogy to linked text frames.

>
> My idea is simply that table rows in table items should behave like text lines in text items.
> So you would display as many rows as fit and then drop the rest and display an overflow marker.

I like this idea, however we are getting into breaking of tables,
which is out of scope for my project. But it can't hurt to discuss
this a little, so lets follow your train of thought.

> Then a linked table item would be told the first row to display and so on.

If we play with the idea that I'd implement linked table frames like
this, things that needs to be taken into consideration with this
approach (and any other approach for breaking tables for that matter)
are then:

What granularity of breaking do we want? Do we want to be able to
break individual rows into two parts, where as much as possible of the
row is shown on the first table frame, and then continuing on the
second (default behavior of e.g. MS Word and LibreOffice)? Or would it
suffice for a first implementation to just "move" the entire row over
to the next table frame? The latter approach is certainly the easiest
to implement. If the former is implemented, I imagine the table would
internally work with a set of N linked text frames per cell, where N
is the number of table frames the cell is visible in.

Another thing to consider is, if we do not implement the first
behavior above, but only the second, more primitive, behavior, we'll
run into the problem of what to do with a cell that spans multiple
rows and then ends up on the boundary between two linked table frames.
How would we handle this? There's no good answer to that question I
believe.

Lastly, how do we handle width of two linked table frames? Should they
both be locked to the same width? Would it even make sense if they
were not, or what would the behavior be?

But these are all run-of-the-mill issues that any table breaking
implementation will have to wrestle with. So let's hold off on this
for a while, because I think we're getting ahead of ourselves.

So lets get back to how the tables I'll be implementing should work in
their initial version.

To make sure I understand you right, I've drawn a picture and attached
it. Is that how you imagine it to work?

What do you others think of this? I kind of like it. I think not
having individual rows automatically grow will get frustrating, but
having the entire frame automatically grow I think diverges too much
from "the Scribus way". So I think this is a good middle ground. And I
also like Andreas' idea of linked table frames, even thought that is
for the future.

Regards,
Elvis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: table_overflowing.png
Type: image/png
Size: 21759 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110517/41f24e0b/attachment-0001.png>

From cbradney at scribus.info  Tue May 17 19:54:55 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Tue, 17 May 2011 21:54:55 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<4DD10652.9090801@xox.ch>	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>	<4DD25D36.2000608@xox.ch>	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>	<4DD26952.20904@iglou.com>	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
Message-ID: <4DD2D28F.9050004@scribus.info>


> What do you others think of this? I kind of like it. I think not
> having individual rows automatically grow will get frustrating, but
> having the entire frame automatically grow I think diverges too much
> from "the Scribus way". So I think this is a good middle ground. And I
> also like Andreas' idea of linked table frames, even thought that is
> for the future.
> 
>

Looking at the diagram, yes, I think automagic row expansion until the
point of disappearing off the bottom of the frame makes the most sense,
as well as fitting within the "Scribus way", as you say.

Craig


From elvstone at gmail.com  Tue May 17 20:00:32 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 22:00:32 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <4DD2D28F.9050004@scribus.info>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
Message-ID: <BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>

Hi Craig,

2011/5/17 Craig Bradney <cbradney at scribus.info>:
>
>> What do you others think of this? I kind of like it. I think not
>> having individual rows automatically grow will get frustrating, but
>> having the entire frame automatically grow I think diverges too much
>> from "the Scribus way". So I think this is a good middle ground. And I
>> also like Andreas' idea of linked table frames, even thought that is
>> for the future.
>>
>>
>
> Looking at the diagram, yes, I think automagic row expansion until the
> point of disappearing off the bottom of the frame makes the most sense,
> as well as fitting within the "Scribus way", as you say.

Good, then I'll put a mental "approved" stamp on that idea.

I'll also try to summarize the outcome of this thread and update my
wiki page with its conclusions.

Elvis


From gpittman at iglou.com  Tue May 17 20:14:38 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Tue, 17 May 2011 16:14:38 -0400
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<4DD10652.9090801@xox.ch>	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>	<4DD25D36.2000608@xox.ch>	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>	<4DD26952.20904@iglou.com>	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
Message-ID: <4DD2D72E.3030709@iglou.com>

On 05/17/2011 04:00 PM, Elvis Stansvik wrote:
> Hi Craig,
>
> 2011/5/17 Craig Bradney<cbradney at scribus.info>:
>>
>>> What do you others think of this? I kind of like it. I think not
>>> having individual rows automatically grow will get frustrating, but
>>> having the entire frame automatically grow I think diverges too much
>>> from "the Scribus way". So I think this is a good middle ground. And I
>>> also like Andreas' idea of linked table frames, even thought that is
>>> for the future.
>>>
>>>
>>
>> Looking at the diagram, yes, I think automagic row expansion until the
>> point of disappearing off the bottom of the frame makes the most sense,
>> as well as fitting within the "Scribus way", as you say.
>
> Good, then I'll put a mental "approved" stamp on that idea.
>
> I'll also try to summarize the outcome of this thread and update my
> wiki page with its conclusions.

Hopefully, there can also be something for the user, who would now say, 
"Now what do I do with this overflowing table?". I would hope he could 
chop off rows and paste somewhere else, maybe even join to the next 
sub-table.

Greg


From elvstone at gmail.com  Tue May 17 20:56:45 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 17 May 2011 22:56:45 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <4DD2D72E.3030709@iglou.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
Message-ID: <BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>

2011/5/17 Gregory Pittman <gpittman at iglou.com>:
> On 05/17/2011 04:00 PM, Elvis Stansvik wrote:
>>
>> Hi Craig,
>>
>> 2011/5/17 Craig Bradney<cbradney at scribus.info>:
>>>
>>>> What do you others think of this? I kind of like it. I think not
>>>> having individual rows automatically grow will get frustrating, but
>>>> having the entire frame automatically grow I think diverges too much
>>>> from "the Scribus way". So I think this is a good middle ground. And I
>>>> also like Andreas' idea of linked table frames, even thought that is
>>>> for the future.
>>>>
>>>>
>>>
>>> Looking at the diagram, yes, I think automagic row expansion until the
>>> point of disappearing off the bottom of the frame makes the most sense,
>>> as well as fitting within the "Scribus way", as you say.
>>
>> Good, then I'll put a mental "approved" stamp on that idea.
>>
>> I'll also try to summarize the outcome of this thread and update my
>> wiki page with its conclusions.
>
> Hopefully, there can also be something for the user, who would now say, "Now
> what do I do with this overflowing table?". I would hope he could chop off
> rows and paste somewhere else, maybe even join to the next sub-table.

Yes, I'll try to come up with a good solution for this, in lieu of
properly linked table frames as discussed above. Who knows, maybe I'll
have time left to actually take a shot at linked table frames before
summer is over. But I prioritize getting the basics done first. But a
way to transfer a range of rows to a new table is definitely something
that should be possible.

Elvis


From elvstone at gmail.com  Wed May 18 15:34:52 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 18 May 2011 17:34:52 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
Message-ID: <BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>

Hi again,

2011/5/17 Elvis Stansvik <elvstone at gmail.com>:
> 2011/5/17 Gregory Pittman <gpittman at iglou.com>:
>> On 05/17/2011 04:00 PM, Elvis Stansvik wrote:
>>>
>>> Hi Craig,
>>>
>>> 2011/5/17 Craig Bradney<cbradney at scribus.info>:
>>>>
>>>>> What do you others think of this? I kind of like it. I think not
>>>>> having individual rows automatically grow will get frustrating, but
>>>>> having the entire frame automatically grow I think diverges too much
>>>>> from "the Scribus way". So I think this is a good middle ground. And I
>>>>> also like Andreas' idea of linked table frames, even thought that is
>>>>> for the future.
>>>>>
>>>>>
>>>>
>>>> Looking at the diagram, yes, I think automagic row expansion until the
>>>> point of disappearing off the bottom of the frame makes the most sense,
>>>> as well as fitting within the "Scribus way", as you say.
>>>
>>> Good, then I'll put a mental "approved" stamp on that idea.
>>>
>>> I'll also try to summarize the outcome of this thread and update my
>>> wiki page with its conclusions.
>>
>> Hopefully, there can also be something for the user, who would now say, "Now
>> what do I do with this overflowing table?". I would hope he could chop off
>> rows and paste somewhere else, maybe even join to the next sub-table.
>
> Yes, I'll try to come up with a good solution for this, in lieu of
> properly linked table frames as discussed above. Who knows, maybe I'll
> have time left to actually take a shot at linked table frames before
> summer is over. But I prioritize getting the basics done first. But a
> way to transfer a range of rows to a new table is definitely something
> that should be possible.

So to conclude this thread, first of all thank you all for taking your
time to answer.

I've now incorporated most of the ideas discussed here in my wiki
page, which I've moved to

http://wiki.scribus.net/canvas/GSoC_2011_Tables_Design

I also took the liberty of making a subcategory to the Development
category called "Tables" and put all table development related pages I
could find into this category, including my own.

I've also created a set of mockups of the most common table editing
operations and put them on the wiki page. For those who have the time,
please take a look at them and see if there's something you find
strange.

While summarizing the thread, I also came to think of another thing;
how do we want the table width to react when the table frame is
resized? Should it follow the frame width, or should the width of the
table be completely independent of the frame width? Or should there be
something similar to what we have for images ("To Frame Size" in the
Scaling properties)?

And should there be no way for the user to resize both the width and
height of the table and have the row heights and column widths follow
proportionally? Isn't that a valid use case?

So still some questions to work out regarding the interaction design.
But we're doing good progress.

Best regards,
Elvis


From ale.comp_06 at xox.ch  Wed May 18 16:05:30 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Wed, 18 May 2011 18:05:30 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
Message-ID: <20110518180530.38d3a691@eisflach>

hi

> While summarizing the thread, I also came to think of another thing;
> how do we want the table width to react when the table frame is
> resized? Should it follow the frame width, or should the width of the
> table be completely independent of the frame width? Or should there be
> something similar to what we have for images ("To Frame Size" in the
> Scaling properties)?
> 
> And should there be no way for the user to resize both the width and
> height of the table and have the row heights and column widths follow
> proportionally? Isn't that a valid use case?

personally, when i create a table there are good chances that i want to have full control on the size of the cells. this is even more true in a DTP context.

i won't define the cells one by one, but i will tend to have a fixed width for the columns and a fixed height for the rows (not all the rows and columns being equal, of course... but probably most of them).

so, to me, it's very important to be able to easily redefine widths and heights. on the other hand, an automatic resize will rather make my work harder than facilitate it.

of course, there should be an easy way to import tables from *office (where the cells automatically grow) and it should be possible to make the cells fit from the scripter (for tables created from csv files; and we already have a way to test for overflowing text...).


finally, when the table is resized, i'd prefer to see a "gray" area which invites me to resize the columns or the rows (i could imagine a context menu on the "gray" area which lets me equally or proportionally distribute the exceeding / missing width to each column or resize just one specific column).


and, of course, this is my own personal opinion!

ciao
a.l.e


From elvstone at gmail.com  Wed May 18 16:49:52 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 18 May 2011 18:49:52 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <20110518180530.38d3a691@eisflach>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
Message-ID: <BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>

Hi a.l.e.

2011/5/18 a.l.e <ale.comp_06 at xox.ch>:
> hi
>
>> While summarizing the thread, I also came to think of another thing;
>> how do we want the table width to react when the table frame is
>> resized? Should it follow the frame width, or should the width of the
>> table be completely independent of the frame width? Or should there be
>> something similar to what we have for images ("To Frame Size" in the
>> Scaling properties)?
>>
>> And should there be no way for the user to resize both the width and
>> height of the table and have the row heights and column widths follow
>> proportionally? Isn't that a valid use case?
>
> personally, when i create a table there are good chances that i want to have full control on the size of the cells. this is even more true in a DTP context.
>
> i won't define the cells one by one, but i will tend to have a fixed width for the columns and a fixed height for the rows (not all the rows and columns being equal, of course... but probably most of them).

Yes, I imagine this is the most common way of working and of course we
should support that.

>
> so, to me, it's very important to be able to easily redefine widths and heights. on the other hand, an automatic resize will rather make my work harder than facilitate it.

I did not mean for this to be the only way of resizing a table of
course. It's just that I see that it's the default behavior when
resizing a table by dragging it's corners in InDesign; both rows and
columns are scaled proportionally.

Imagine that you had gone through the process of setting up the widths
and heights of the columns and rows like you describe, but then
realize that you need the table just a little bit bigger; without this
feature you would then have to individually make each row and column
slightly bigger. So I think we should at least consider having the
feature, perhaps not the default behavior, but still possible.

Now why I asked was more because I wonder how this will be implemented
as Scribus' tables will be different in that their bottom edge will
not follow the bottom edge of the frame. So how do we give the user
the ability to scale the entire table?

What do you imagine should happen to the table when the user resizes
the table by the way? Nothing? Or should it adapt it's width to the
frame width?

I'm starting to think that nothing at all should happen actually, and
that we should just have an "Adjust Frame to Table" option such as
that available for images.

Then table resizing would be strictly done "inside" the frame, it's
corner could be grabbed to resize it, and with a modifier the
proportional behavior could be enabled, while the default would be to
just resize the last row and column.

>
> of course, there should be an easy way to import tables from *office (where the cells automatically grow) and it should be possible to make the cells fit from the scripter (for tables created from csv files; and we already have a way to test for overflowing text...).

Yes, I understand you favor that rows don't grow automatically, so I
think we should support both auto-growing and fixed. Perhaps I'll
start with the fixed behavior, as that will be easiest to implement.

> finally, when the table is resized, i'd prefer to see a "gray" area which invites me to resize the columns or the rows (i could imagine a context menu on the "gray" area which lets me equally or proportionally distribute the exceeding / missing width to each column or resize just one specific column).

Hm, a context menu on a "gray" gray are seems hard to discover to me
and not very intuitive. But perhaps I'm just not understanding you
right here. Let me make a picture... *makes picture*. Check the
attached picture, is that what you meant? If so, I'm not so sure about
the usability of that..

Now that I think about it, you probably meant the menu should be
visible directly on this gray area, without the user having to
right-click? Then it's a little better, but it's still a pretty
advanced feature. But I like playing with crazy ideas ;)

> and, of course, this is my own personal opinion!

Of course ;)

Elvis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ale_idea.png
Type: image/png
Size: 48051 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110518/f5e9681a/attachment-0001.png>

From elvstone at gmail.com  Wed May 18 16:51:28 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 18 May 2011 18:51:28 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
Message-ID: <BANLkTikg=-EVum9=eu-Vr1w1Lwo-o0ruJA@mail.gmail.com>

2011/5/18 Elvis Stansvik <elvstone at gmail.com>:
> Hi a.l.e.
>
> 2011/5/18 a.l.e <ale.comp_06 at xox.ch>:
>> hi
>>
>>> While summarizing the thread, I also came to think of another thing;
>>> how do we want the table width to react when the table frame is
>>> resized? Should it follow the frame width, or should the width of the
>>> table be completely independent of the frame width? Or should there be
>>> something similar to what we have for images ("To Frame Size" in the
>>> Scaling properties)?
>>>
>>> And should there be no way for the user to resize both the width and
>>> height of the table and have the row heights and column widths follow
>>> proportionally? Isn't that a valid use case?
>>
>> personally, when i create a table there are good chances that i want to have full control on the size of the cells. this is even more true in a DTP context.
>>
>> i won't define the cells one by one, but i will tend to have a fixed width for the columns and a fixed height for the rows (not all the rows and columns being equal, of course... but probably most of them).
>
> Yes, I imagine this is the most common way of working and of course we
> should support that.
>
>>
>> so, to me, it's very important to be able to easily redefine widths and heights. on the other hand, an automatic resize will rather make my work harder than facilitate it.
>
> I did not mean for this to be the only way of resizing a table of
> course. It's just that I see that it's the default behavior when
> resizing a table by dragging it's corners in InDesign; both rows and
> columns are scaled proportionally.
>
> Imagine that you had gone through the process of setting up the widths
> and heights of the columns and rows like you describe, but then
> realize that you need the table just a little bit bigger; without this
> feature you would then have to individually make each row and column
> slightly bigger. So I think we should at least consider having the
> feature, perhaps not the default behavior, but still possible.
>
> Now why I asked was more because I wonder how this will be implemented
> as Scribus' tables will be different in that their bottom edge will
> not follow the bottom edge of the frame. So how do we give the user
> the ability to scale the entire table?
>
> What do you imagine should happen to the table when the user resizes
> the table by the way? Nothing? Or should it adapt it's width to the
> frame width?

Here I mean "resizes the table _frame_" of course.

Elvis

>
> I'm starting to think that nothing at all should happen actually, and
> that we should just have an "Adjust Frame to Table" option such as
> that available for images.
>
> Then table resizing would be strictly done "inside" the frame, it's
> corner could be grabbed to resize it, and with a modifier the
> proportional behavior could be enabled, while the default would be to
> just resize the last row and column.
>
>>
>> of course, there should be an easy way to import tables from *office (where the cells automatically grow) and it should be possible to make the cells fit from the scripter (for tables created from csv files; and we already have a way to test for overflowing text...).
>
> Yes, I understand you favor that rows don't grow automatically, so I
> think we should support both auto-growing and fixed. Perhaps I'll
> start with the fixed behavior, as that will be easiest to implement.
>
>> finally, when the table is resized, i'd prefer to see a "gray" area which invites me to resize the columns or the rows (i could imagine a context menu on the "gray" area which lets me equally or proportionally distribute the exceeding / missing width to each column or resize just one specific column).
>
> Hm, a context menu on a "gray" gray are seems hard to discover to me
> and not very intuitive. But perhaps I'm just not understanding you
> right here. Let me make a picture... *makes picture*. Check the
> attached picture, is that what you meant? If so, I'm not so sure about
> the usability of that..
>
> Now that I think about it, you probably meant the menu should be
> visible directly on this gray area, without the user having to
> right-click? Then it's a little better, but it's still a pretty
> advanced feature. But I like playing with crazy ideas ;)
>
>> and, of course, this is my own personal opinion!
>
> Of course ;)
>
> Elvis
>


From Ralf-Diether.Ebel at gmx.de  Wed May 18 18:25:04 2011
From: Ralf-Diether.Ebel at gmx.de (Ralf-Diether Ebel)
Date: Wed, 18 May 2011 20:25:04 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<4DD10652.9090801@xox.ch>	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>	<4DD25D36.2000608@xox.ch>	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>	<4DD26952.20904@iglou.com>	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>	<4DD2D28F.9050004@scribus.info>	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>	<4DD2D72E.3030709@iglou.com>	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
Message-ID: <4DD40F00.3070303@gmx.de>

Hello Elvis,

On 18.05.2011 17:34, Elvis Stansvik wrote:
<....>
> I've now incorporated most of the ideas discussed here in my wiki
> page, which I've moved to
>
> http://wiki.scribus.net/canvas/GSoC_2011_Tables_Design
...
> I've also created a set of mockups of the most common table editing
> operations and put them on the wiki page. For those who have the time,
> please take a look at them and see if there's something you find
> strange.

I followed the thread and find it very interesting.
Coming to "Selecting cells" in the wiki mentioned above I wonder why 
the selection modifier <alt> is used. In Calc (Excel) normally <ctrl> 
is used for this.

With kind regards,
Ralf Ebel



From ale.comp_06 at xox.ch  Wed May 18 18:46:26 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Wed, 18 May 2011 20:46:26 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
Message-ID: <20110518204626.354221ba@eisflach>

hi elvis,

> Now that I think about it, you probably meant the menu should be
> visible directly on this gray area, without the user having to
> right-click? Then it's a little better, but it's still a pretty
> advanced feature. But I like playing with crazy ideas ;)

you got it 100% with your schema!

shrinking the table won't be as "nice"... but should also be doable.

and yes, i was writing about a right click for a context menu... but -- as for every function in scribus -- you will find the same command also in the main navigation.

ciao
a.l.e


From ale.comp_06 at xox.ch  Wed May 18 19:20:02 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Wed, 18 May 2011 21:20:02 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <4DD40F00.3070303@gmx.de>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<4DD40F00.3070303@gmx.de>
Message-ID: <20110518212002.37e7452a@eisflach>


hi Ralf-Diether,

> On 18.05.2011 17:34, Elvis Stansvik wrote:
> <....>
> > I've now incorporated most of the ideas discussed here in my wiki
> > page, which I've moved to
> >
> > http://wiki.scribus.net/canvas/GSoC_2011_Tables_Design
> ...
> > I've also created a set of mockups of the most common table editing
> > operations and put them on the wiki page. For those who have the
> > time, please take a look at them and see if there's something you
> > find strange.
> 
> I followed the thread and find it very interesting.
> Coming to "Selecting cells" in the wiki mentioned above I wonder why 
> the selection modifier <alt> is used. In Calc (Excel) normally <ctrl> 
> is used for this.

because ctrl is used to select the frames hidden by another frame...

i just noticed that inkscape is using alt for this... i wonder if scribus should change its behavior...


ciao
a.l.e


From elvstone at gmail.com  Wed May 18 19:30:24 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 18 May 2011 21:30:24 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <20110518204626.354221ba@eisflach>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
	<20110518204626.354221ba@eisflach>
Message-ID: <BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>

2011/5/18 a.l.e <ale.comp_06 at xox.ch>:
> hi elvis,
>
>> Now that I think about it, you probably meant the menu should be
>> visible directly on this gray area, without the user having to
>> right-click? Then it's a little better, but it's still a pretty
>> advanced feature. But I like playing with crazy ideas ;)
>
> you got it 100% with your schema!
>
> shrinking the table won't be as "nice"... but should also be doable.

Alright, but then I guess you mean that the user would confirm these
choices somehow (distribute vs. giving explicit sizes to rows columns)
for the table size change to finally take effect? It feels like a bit
much work for the user for just changing the size of a table. Or
rather, it feels like a power feature, and one that diverges quite a
lot from established ways of working with tables in other software.
But of course it's good to be open to new innovative ideas, so I'm not
saying I'm completely against it.

But anyway, I feel that things are starting to crystallize more now.
And a lot of good has come out of this thread.

> and yes, i was writing about a right click for a context menu... but -- as for every function in scribus -- you will find the same command also in the main navigation.

Hm, yes. But this state where the gray area is shown, it feels like a
transient (temporary) state only visible right after the user has
requested a resize of a table by dragging its corners. Should menu
actions related to such a contextual/transient action really be
visible somewhere in the main menus of Scribus? I'm not sure.. But
anyway, these are details for later I think.

Regards,
Elvis


From ale.comp_06 at xox.ch  Wed May 18 20:35:15 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Wed, 18 May 2011 22:35:15 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
	<20110518204626.354221ba@eisflach>
	<BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>
Message-ID: <20110518223515.13c0edd0@eisflach>

hi elvis,

> >> Now that I think about it, you probably meant the menu should be
> >> visible directly on this gray area, without the user having to
> >> right-click? Then it's a little better, but it's still a pretty
> >> advanced feature. But I like playing with crazy ideas ;)
> >
> > you got it 100% with your schema!
> >
> > shrinking the table won't be as "nice"... but should also be doable.
> 
> Alright, but then I guess you mean that the user would confirm these
> choices somehow (distribute vs. giving explicit sizes to rows columns)
> for the table size change to finally take effect? It feels like a bit
> much work for the user for just changing the size of a table. Or
> rather, it feels like a power feature, and one that diverges quite a
> lot from established ways of working with tables in other software.
> But of course it's good to be open to new innovative ideas, so I'm not
> saying I'm completely against it.

personally, i'm mostly struggling with the way most software handles table resizing...
(i admit that i don't work much with tables, though... and that i avoid resizing them!)

however, no, the user should not confirm each choice. here a typical workflow:
- the user creates a table with equal width columns / rows (or by defining custom measurements in the insert table dialog)
- she can interactively resize columns and rows
  (btw, what happens if she shrinks the height of a row? do the other rows grow? does the whole table shrink? there is no correct way to handle this: i think this also a case for the gray area...)
- at some time later she resizes the table to a new size
- the cells are not resized
- once the user is sure of the new size, she choses among four ways of solving the "issue" by using the context menu (or the main item menu):
  - resize each cell proportionally (depends on the current size),
  - resize each cell by the same amount each
  - resize only one column / row
  - resize the table to fit the cells (horizontal / vertical) size (goes back to the previous state)
  those context menu items could appear when you right click on a table and the cells don't fill the table frame.



> But anyway, I feel that things are starting to crystallize more now.
> And a lot of good has come out of this thread.
> 
> > and yes, i was writing about a right click for a context menu...
> > but -- as for every function in scribus -- you will find the same
> > command also in the main navigation.
> 
> Hm, yes. But this state where the gray area is shown, it feels like a
> transient (temporary) state only visible right after the user has
> requested a resize of a table by dragging its corners. Should menu
> actions related to such a contextual/transient action really be
> visible somewhere in the main menus of Scribus? I'm not sure.. But
> anyway, these are details for later I think.

the gray area is shown until the user has not set the cells size to fill the table size (and a warning is issued in the preflight verifier if the user does not so)

the user can also manually change the sizes to fill the table area (or not to so, if she does not want it).

that's the way i see it working :-)

i agree that it's not the way most program do work, but it would finally be a way that works for me! :-)
no more fights to get the correct result when resizing a table.
(to the defense of the other apps: there is no one correct way to handle the table resizing. it all depends on the content of the columns and rows!)

ciao
a.l.e


From elvstone at gmail.com  Wed May 18 20:40:15 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 18 May 2011 22:40:15 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <20110518223515.13c0edd0@eisflach>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
	<20110518204626.354221ba@eisflach>
	<BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>
	<20110518223515.13c0edd0@eisflach>
Message-ID: <BANLkTim5B+vTsWp9MSq5bb1fknns+ph82Q@mail.gmail.com>

2011/5/18 a.l.e <ale.comp_06 at xox.ch>:
> hi elvis,
>
>> >> Now that I think about it, you probably meant the menu should be
>> >> visible directly on this gray area, without the user having to
>> >> right-click? Then it's a little better, but it's still a pretty
>> >> advanced feature. But I like playing with crazy ideas ;)
>> >
>> > you got it 100% with your schema!
>> >
>> > shrinking the table won't be as "nice"... but should also be doable.
>>
>> Alright, but then I guess you mean that the user would confirm these
>> choices somehow (distribute vs. giving explicit sizes to rows columns)
>> for the table size change to finally take effect? It feels like a bit
>> much work for the user for just changing the size of a table. Or
>> rather, it feels like a power feature, and one that diverges quite a
>> lot from established ways of working with tables in other software.
>> But of course it's good to be open to new innovative ideas, so I'm not
>> saying I'm completely against it.
>
> personally, i'm mostly struggling with the way most software handles table resizing...
> (i admit that i don't work much with tables, though... and that i avoid resizing them!)
>
> however, no, the user should not confirm each choice. here a typical workflow:
> - the user creates a table with equal width columns / rows (or by defining custom measurements in the insert table dialog)
> - she can interactively resize columns and rows
> ?(btw, what happens if she shrinks the height of a row? do the other rows grow? does the whole table shrink? there is no correct way to handle this: i think this also a case for the gray area...)
> - at some time later she resizes the table to a new size
> - the cells are not resized
> - once the user is sure of the new size, she choses among four ways of solving the "issue" by using the context menu (or the main item menu):
> ?- resize each cell proportionally (depends on the current size),
> ?- resize each cell by the same amount each
> ?- resize only one column / row
> ?- resize the table to fit the cells (horizontal / vertical) size (goes back to the previous state)
> ?those context menu items could appear when you right click on a table and the cells don't fill the table frame.

Thanks a lot for the clear explanation. I think I understand
everything you're trying to say now. I think something to this effect
could be useful indeed, while the workflow might need a little work.
But I agree with you 100% that there's really no way to guess how the
user wants the table to be resized, so we need to find something that
works well and gives the user the control he/she needs. We'll revisit
this once I reach this part of the project.

Elvis

>> But anyway, I feel that things are starting to crystallize more now.
>> And a lot of good has come out of this thread.
>>
>> > and yes, i was writing about a right click for a context menu...
>> > but -- as for every function in scribus -- you will find the same
>> > command also in the main navigation.
>>
>> Hm, yes. But this state where the gray area is shown, it feels like a
>> transient (temporary) state only visible right after the user has
>> requested a resize of a table by dragging its corners. Should menu
>> actions related to such a contextual/transient action really be
>> visible somewhere in the main menus of Scribus? I'm not sure.. But
>> anyway, these are details for later I think.
>
> the gray area is shown until the user has not set the cells size to fill the table size (and a warning is issued in the preflight verifier if the user does not so)
>
> the user can also manually change the sizes to fill the table area (or not to so, if she does not want it).
>
> that's the way i see it working :-)
>
> i agree that it's not the way most program do work, but it would finally be a way that works for me! :-)

:)

> no more fights to get the correct result when resizing a table.
> (to the defense of the other apps: there is no one correct way to handle the table resizing. it all depends on the content of the columns and rows!)

Right.

Elvis


From gpittman at iglou.com  Wed May 18 21:35:36 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Wed, 18 May 2011 17:35:36 -0400
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTim5B+vTsWp9MSq5bb1fknns+ph82Q@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<4DD10652.9090801@xox.ch>	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>	<4DD25D36.2000608@xox.ch>	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>	<4DD26952.20904@iglou.com>	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>	<4DD2D28F.9050004@scribus.info>	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>	<4DD2D72E.3030709@iglou.com>	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>	<20110518180530.38d3a691@eisflach>	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>	<20110518204626.354221ba@eisflach>	<BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>	<20110518223515.13c0edd0@eisflach>
	<BANLkTim5B+vTsWp9MSq5bb1fknns+ph82Q@mail.gmail.com>
Message-ID: <4DD43BA8.6030901@iglou.com>

On 05/18/2011 04:40 PM, Elvis Stansvik wrote:
> 2011/5/18 a.l.e<ale.comp_06 at xox.ch>:

>> no more fights to get the correct result when resizing a table.
>> (to the defense of the other apps: there is no one correct way to handle the table resizing. it all depends on the content of the columns and rows!)
>
> Right.

Something else needed (unless I missed it on your wiki page) is a 
"colspan"-like function, to combine two or more adjacent cells to one 
larger cell.

Greg


From andreas.vox at googlemail.com  Wed May 18 22:05:34 2011
From: andreas.vox at googlemail.com (Andreas Vox)
Date: Thu, 19 May 2011 00:05:34 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
Message-ID: <47639A8D-BE2A-423E-BC93-B47D987DC2C8@googlemail.com>


Am 18.05.2011 um 18:49 schrieb Elvis Stansvik:

> Hi a.l.e.
> 
> 2011/5/18 a.l.e <ale.comp_06 at xox.ch>:
>> hi
>> 
>>> While summarizing the thread, I also came to think of another thing;
>>> how do we want the table width to react when the table frame is
>>> resized? Should it follow the frame width, or should the width of the
>>> table be completely independent of the frame width? Or should there be
>>> something similar to what we have for images ("To Frame Size" in the
>>> Scaling properties)?
>>> 
>>> And should there be no way for the user to resize both the width and
>>> height of the table and have the row heights and column widths follow
>>> proportionally? Isn't that a valid use case?
>> 
>> personally, when i create a table there are good chances that i want to have full control on the size of the cells. this is even more true in a DTP context.
>> 
>> i won't define the cells one by one, but i will tend to have a fixed width for the columns and a fixed height for the rows (not all the rows and columns being equal, of course... but probably most of them).
> 
> Yes, I imagine this is the most common way of working and of course we
> should support that.
> 
>> 
>> so, to me, it's very important to be able to easily redefine widths and heights. on the other hand, an automatic resize will rather make my work harder than facilitate it.
> 
> I did not mean for this to be the only way of resizing a table of
> course. It's just that I see that it's the default behavior when
> resizing a table by dragging it's corners in InDesign; both rows and
> columns are scaled proportionally.
> 
> Imagine that you had gone through the process of setting up the widths
> and heights of the columns and rows like you describe, but then
> realize that you need the table just a little bit bigger; without this
> feature you would then have to individually make each row and column
> slightly bigger. So I think we should at least consider having the
> feature, perhaps not the default behavior, but still possible.
> 
> Now why I asked was more because I wonder how this will be implemented
> as Scribus' tables will be different in that their bottom edge will
> not follow the bottom edge of the frame. So how do we give the user
> the ability to scale the entire table?
> 
> What do you imagine should happen to the table when the user resizes
> the table by the way? Nothing? Or should it adapt it's width to the
> frame width?
> 
> I'm starting to think that nothing at all should happen actually, and
> that we should just have an "Adjust Frame to Table" option such as
> that available for images.
> 
> Then table resizing would be strictly done "inside" the frame, it's
> corner could be grabbed to resize it, and with a modifier the
> proportional behavior could be enabled, while the default would be to
> just resize the last row and column.
> 
>> 
>> of course, there should be an easy way to import tables from *office (where the cells automatically grow) and it should be possible to make the cells fit from the scripter (for tables created from csv files; and we already have a way to test for overflowing text...).
> 
> Yes, I understand you favor that rows don't grow automatically, so I
> think we should support both auto-growing and fixed. Perhaps I'll
> start with the fixed behavior, as that will be easiest to implement.
> 
>> finally, when the table is resized, i'd prefer to see a "gray" area which invites me to resize the columns or the rows (i could imagine a context menu on the "gray" area which lets me equally or proportionally distribute the exceeding / missing width to each column or resize just one specific column).
> 

Hmm. If we have the following options for column widths, it should be easy to resize columns:

- min width (default: 0)
- max width (default: infinity)
- weight (default: 1)

Then we could assign each column its minimal width and calculate the remaining space. Using the weight, the remaining space is distributed to the columns. Then, for each column which is now wider than it's maximum width, it's reset to its maximum width and weight 0 and the extra space is distributed among the remaining columns.

If the sum of all minimum width is larger than the table width, the table is clipped at the right.
If the sum of maximum widths is less than the table width, a gray area appears at the right.


Similar for rows:
- min height (default: auto, ie. depending on the contained text)
- max height (default: infinity)
- weight (default: 0, ie. rows stack up to the top with a gray area at the bottom)


Note: gray areas should be rendered transparent for print and PDF export.


Makes sense?

/Andreas

From elvstone at gmail.com  Wed May 18 22:28:11 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Thu, 19 May 2011 00:28:11 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <4DD43BA8.6030901@iglou.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
	<20110518204626.354221ba@eisflach>
	<BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>
	<20110518223515.13c0edd0@eisflach>
	<BANLkTim5B+vTsWp9MSq5bb1fknns+ph82Q@mail.gmail.com>
	<4DD43BA8.6030901@iglou.com>
Message-ID: <BANLkTi=EdmSeK112dMz2RWc95THcew5KzA@mail.gmail.com>

2011/5/18 Gregory Pittman <gpittman at iglou.com>:
> On 05/18/2011 04:40 PM, Elvis Stansvik wrote:
>>
>> 2011/5/18 a.l.e<ale.comp_06 at xox.ch>:
>
>>> no more fights to get the correct result when resizing a table.
>>> (to the defense of the other apps: there is no one correct way to handle
>>> the table resizing. it all depends on the content of the columns and rows!)
>>
>> Right.
>
> Something else needed (unless I missed it on your wiki page) is a
> "colspan"-like function, to combine two or more adjacent cells to one larger
> cell.

Yes, can't believe I missed that. Merging and splitting of cells
should of course be supported. It is in my project proposal, just
forgot to put it on the wiki page. Thanks for reminding me.

Elvis


From elvstone at gmail.com  Thu May 19 09:01:10 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Thu, 19 May 2011 11:01:10 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <20110518223515.13c0edd0@eisflach>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
	<20110518204626.354221ba@eisflach>
	<BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>
	<20110518223515.13c0edd0@eisflach>
Message-ID: <BANLkTin2PVuAOjeGGxpHwi85HAvGSzX4pw@mail.gmail.com>

2011/5/18 a.l.e <ale.comp_06 at xox.ch>:
> hi elvis,
>
>> >> Now that I think about it, you probably meant the menu should be
>> >> visible directly on this gray area, without the user having to
>> >> right-click? Then it's a little better, but it's still a pretty
>> >> advanced feature. But I like playing with crazy ideas ;)
>> >
>> > you got it 100% with your schema!
>> >
>> > shrinking the table won't be as "nice"... but should also be doable.
>>
>> Alright, but then I guess you mean that the user would confirm these
>> choices somehow (distribute vs. giving explicit sizes to rows columns)
>> for the table size change to finally take effect? It feels like a bit
>> much work for the user for just changing the size of a table. Or
>> rather, it feels like a power feature, and one that diverges quite a
>> lot from established ways of working with tables in other software.
>> But of course it's good to be open to new innovative ideas, so I'm not
>> saying I'm completely against it.
>
> personally, i'm mostly struggling with the way most software handles table resizing...
> (i admit that i don't work much with tables, though... and that i avoid resizing them!)
>
> however, no, the user should not confirm each choice. here a typical workflow:
> - the user creates a table with equal width columns / rows (or by defining custom measurements in the insert table dialog)
> - she can interactively resize columns and rows
> ?(btw, what happens if she shrinks the height of a row? do the other rows grow? does the whole table shrink? there is no correct way to handle this: i think this also a case for the gray area...)
> - at some time later she resizes the table to a new size
> - the cells are not resized
> - once the user is sure of the new size, she choses among four ways of solving the "issue" by using the context menu (or the main item menu):
> ?- resize each cell proportionally (depends on the current size),
> ?- resize each cell by the same amount each
> ?- resize only one column / row
> ?- resize the table to fit the cells (horizontal / vertical) size (goes back to the previous state)
> ?those context menu items could appear when you right click on a table and the cells don't fill the table frame.

Inspired by your ideas, I made a mockup of a similar workflow for
resizing tables that I think could work out:

http://wiki.scribus.net/wiki/images/4/4e/Resizing_table_workflow_mockup.png

Elvis

>
>
>
>> But anyway, I feel that things are starting to crystallize more now.
>> And a lot of good has come out of this thread.
>>
>> > and yes, i was writing about a right click for a context menu...
>> > but -- as for every function in scribus -- you will find the same
>> > command also in the main navigation.
>>
>> Hm, yes. But this state where the gray area is shown, it feels like a
>> transient (temporary) state only visible right after the user has
>> requested a resize of a table by dragging its corners. Should menu
>> actions related to such a contextual/transient action really be
>> visible somewhere in the main menus of Scribus? I'm not sure.. But
>> anyway, these are details for later I think.
>
> the gray area is shown until the user has not set the cells size to fill the table size (and a warning is issued in the preflight verifier if the user does not so)
>
> the user can also manually change the sizes to fill the table area (or not to so, if she does not want it).
>
> that's the way i see it working :-)
>
> i agree that it's not the way most program do work, but it would finally be a way that works for me! :-)
> no more fights to get the correct result when resizing a table.
> (to the defense of the other apps: there is no one correct way to handle the table resizing. it all depends on the content of the columns and rows!)
>
> ciao
> a.l.e
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From elvstone at gmail.com  Thu May 19 09:24:43 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Thu, 19 May 2011 11:24:43 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTin2PVuAOjeGGxpHwi85HAvGSzX4pw@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<4DD10652.9090801@xox.ch>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
	<20110518204626.354221ba@eisflach>
	<BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>
	<20110518223515.13c0edd0@eisflach>
	<BANLkTin2PVuAOjeGGxpHwi85HAvGSzX4pw@mail.gmail.com>
Message-ID: <BANLkTinweb4o947URxR0=MRTo2T+ePpiVQ@mail.gmail.com>

2011/5/19 Elvis Stansvik <elvstone at gmail.com>:
> 2011/5/18 a.l.e <ale.comp_06 at xox.ch>:
>> hi elvis,
>>
>>> >> Now that I think about it, you probably meant the menu should be
>>> >> visible directly on this gray area, without the user having to
>>> >> right-click? Then it's a little better, but it's still a pretty
>>> >> advanced feature. But I like playing with crazy ideas ;)
>>> >
>>> > you got it 100% with your schema!
>>> >
>>> > shrinking the table won't be as "nice"... but should also be doable.
>>>
>>> Alright, but then I guess you mean that the user would confirm these
>>> choices somehow (distribute vs. giving explicit sizes to rows columns)
>>> for the table size change to finally take effect? It feels like a bit
>>> much work for the user for just changing the size of a table. Or
>>> rather, it feels like a power feature, and one that diverges quite a
>>> lot from established ways of working with tables in other software.
>>> But of course it's good to be open to new innovative ideas, so I'm not
>>> saying I'm completely against it.
>>
>> personally, i'm mostly struggling with the way most software handles table resizing...
>> (i admit that i don't work much with tables, though... and that i avoid resizing them!)
>>
>> however, no, the user should not confirm each choice. here a typical workflow:
>> - the user creates a table with equal width columns / rows (or by defining custom measurements in the insert table dialog)
>> - she can interactively resize columns and rows
>> ?(btw, what happens if she shrinks the height of a row? do the other rows grow? does the whole table shrink? there is no correct way to handle this: i think this also a case for the gray area...)
>> - at some time later she resizes the table to a new size
>> - the cells are not resized
>> - once the user is sure of the new size, she choses among four ways of solving the "issue" by using the context menu (or the main item menu):
>> ?- resize each cell proportionally (depends on the current size),
>> ?- resize each cell by the same amount each
>> ?- resize only one column / row
>> ?- resize the table to fit the cells (horizontal / vertical) size (goes back to the previous state)
>> ?those context menu items could appear when you right click on a table and the cells don't fill the table frame.
>
> Inspired by your ideas, I made a mockup of a similar workflow for
> resizing tables that I think could work out:

Some more notes/observations about this:

1) By default, row heights would never shrink below the size of the
cell content, but we could have a table (possibly row) property "Allow
cell frames to overflow" to allow this.
2) With this way of working, table size, both width and height, is
completely detached from frame size. They are not linked in any way.
However, we could have options similar to those for images: "Adjust
Frame to Table" and "Adjust Table to Frame". The latter would show the
same options for distributing the space as shown in the widget in the
mockup.
3) If the user has picked e.g. "Proportional" for distributing
horizontal space, but then starts resizing columns anyway, the combo
in the widget could automatically go to "Manual", as a convenience.

I believe this could work out quite well. A DTP user will know the
exact space she wants to give the table frame on the page, but this
workflow will help her distribute the space of the frame to the table
in an easy way, while still giving her full control if she needs it.

Elvis


From gpittman at iglou.com  Thu May 19 13:39:21 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Thu, 19 May 2011 09:39:21 -0400
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTinweb4o947URxR0=MRTo2T+ePpiVQ@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>	<4DD25D36.2000608@xox.ch>	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>	<4DD26952.20904@iglou.com>	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>	<4DD2D28F.9050004@scribus.info>	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>	<4DD2D72E.3030709@iglou.com>	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>	<20110518180530.38d3a691@eisflach>	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>	<20110518204626.354221ba@eisflach>	<BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>	<20110518223515.13c0edd0@eisflach>	<BANLkTin2PVuAOjeGGxpHwi85HAvGSzX4pw@mail.gmail.com>
	<BANLkTinweb4o947URxR0=MRTo2T+ePpiVQ@mail.gmail.com>
Message-ID: <4DD51D89.1070506@iglou.com>

On 05/19/2011 05:24 AM, Elvis Stansvik wrote:
>
> I believe this could work out quite well. A DTP user will know the
> exact space she wants to give the table frame on the page, but this
> workflow will help her distribute the space of the frame to the table
> in an easy way, while still giving her full control if she needs it.

Hi Elvis,

Just wanted to compliment you on your work. Let's hope the other GSoC 
students are reading your posts and plan to follow your example.

Excellent start!!

Greg


From ale.comp_06 at xox.ch  Thu May 19 14:06:55 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Thu, 19 May 2011 16:06:55 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <4DD51D89.1070506@iglou.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<4DD25D36.2000608@xox.ch>	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>	<4DD26952.20904@iglou.com>	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>	<4DD2D28F.9050004@scribus.info>	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>	<4DD2D72E.3030709@iglou.com>	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>	<20110518180530.38d3a691@eisflach>	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>	<20110518204626.354221ba@eisflach>	<BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>	<20110518223515.13c0edd0@eisflach>	<BANLkTin2PVuAOjeGGxpHwi85HAvGSzX4pw@mail.gmail.com>	<BANLkTinweb4o947URxR0=MRTo2T+ePpiVQ@mail.gmail.com>
	<4DD51D89.1070506@iglou.com>
Message-ID: <4DD523FF.9020505@xox.ch>

hi
>>
> Just wanted to compliment you on your work. Let's hope the other GSoC 
> students are reading your posts and plan to follow your example.
>
> Excellent start!!

i hope that the other GSoC student does not get jealous... until now he 
was asking questions when i did not have any time :-(

but he has also already started working on his project and he is on the 
right track!

ciao
a.l.e


From ale.comp_06 at xox.ch  Thu May 19 16:07:55 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Thu, 19 May 2011 18:07:55 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <BANLkTinweb4o947URxR0=MRTo2T+ePpiVQ@mail.gmail.com>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>	<4DD25D36.2000608@xox.ch>	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>	<4DD26952.20904@iglou.com>	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>	<4DD2D28F.9050004@scribus.info>	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>	<4DD2D72E.3030709@iglou.com>	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>	<20110518180530.38d3a691@eisflach>	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>	<20110518204626.354221ba@eisflach>	<BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>	<20110518223515.13c0edd0@eisflach>	<BANLkTin2PVuAOjeGGxpHwi85HAvGSzX4pw@mail.gmail.com>
	<BANLkTinweb4o947URxR0=MRTo2T+ePpiVQ@mail.gmail.com>
Message-ID: <4DD5405B.9020308@xox.ch>

hi
> 1) By default, row heights would never shrink below the size of the
> cell content, but we could have a table (possibly row) property "Allow
> cell frames to overflow" to allow this.

i don't see a reason for it... text frames can overflow, cells should do 
the same...
but i'd welcome two commands (which are currently missing for text frames):
- resize frame (vertically / horizontally) to fit the text
- delete the overflowing text (useful for lore ipsums and for text 
imported from .odt files (people tend to leave lots of empty lines at 
the end of their files...)

> 2) With this way of working, table size, both width and height, is
> completely detached from frame size. They are not linked in any way.
> However, we could have options similar to those for images: "Adjust
> Frame to Table" and "Adjust Table to Frame". The latter would show the
> same options for distributing the space as shown in the widget in the
> mockup.

yep


> 3) If the user has picked e.g. "Proportional" for distributing
> horizontal space, but then starts resizing columns anyway, the combo
> in the widget could automatically go to "Manual", as a convenience.

personally, i was not thinking of "proportional" as a setting for the 
table, but as a command: distribute proportionally, now!

you will have to launch the command each time you resize the table.

but this is another discussion: what happens when the user increases the 
width of a column?
should the table grow? should the next column shrink? should all other 
collumns shrink?
i wonder what is the workflow which gives the most predictable result 
(and the most tweakable...)
i guess we have to play a bit with it...

ciao
a.l.e





From martin_hosken at sil.org  Fri May 20 06:43:04 2011
From: martin_hosken at sil.org (Martin Hosken)
Date: Fri, 20 May 2011 13:43:04 +0700
Subject: [scribus-dev] state of new text system
Message-ID: <20110520134304.0892ac99@sil-mh5>

Dear All,

I was wondering what the status is on the new text system. Back in bug #1413 mention was made that this would be merged into trunk (or at least made public) "in the new year", and that was back in Oct 2010. 6+ months on, how's it going?

From where I sit, this is a biggy. Enabling OpenType support opens the way for non-Roman script support and some very large markets.

Yours,
Martin


From elvstone at gmail.com  Fri May 20 07:03:37 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Fri, 20 May 2011 09:03:37 +0200
Subject: [scribus-dev] Preparations for GSoC
In-Reply-To: <4DD5405B.9020308@xox.ch>
References: <BANLkTin0CdVOEJ_paT+D2+2u=DePEXcv0g@mail.gmail.com>
	<BANLkTim-jEb3KQ5TWGdCdQm5_6aLSGxyXA@mail.gmail.com>
	<4DD25D36.2000608@xox.ch>
	<BANLkTimCTf9FsWjH-oO99TVjd++qLhEgkg@mail.gmail.com>
	<4DD26952.20904@iglou.com>
	<78C9F701-2E2E-4220-99AA-2C4E2A952E6C@googlemail.com>
	<BANLkTinS8WpRXigcgtwF2nmrdOtDAqd4_g@mail.gmail.com>
	<C5E6EEEA-9EDE-4187-84CE-9E4BD0E8637D@googlemail.com>
	<BANLkTi=bCVFk_zdcE9yH8-VNjdiAZUQh9g@mail.gmail.com>
	<4DD2D28F.9050004@scribus.info>
	<BANLkTinFobx04Vyco_ZBh1=+ZKj05bqrtw@mail.gmail.com>
	<4DD2D72E.3030709@iglou.com>
	<BANLkTimiM8qSQhF-QF7h-G-th7_bKbV_DA@mail.gmail.com>
	<BANLkTikBSHAj51rNj-bGzz54z0KMiCnRpg@mail.gmail.com>
	<20110518180530.38d3a691@eisflach>
	<BANLkTimqgdZYv32jYSK056EEL3e-dcN+Xw@mail.gmail.com>
	<20110518204626.354221ba@eisflach>
	<BANLkTin8+qV2YdM6Rs_DP=hpVTjUwmTUUQ@mail.gmail.com>
	<20110518223515.13c0edd0@eisflach>
	<BANLkTin2PVuAOjeGGxpHwi85HAvGSzX4pw@mail.gmail.com>
	<BANLkTinweb4o947URxR0=MRTo2T+ePpiVQ@mail.gmail.com>
	<4DD5405B.9020308@xox.ch>
Message-ID: <BANLkTikZiZWK4jUnk2=s_9-b3pdwMBC=7Q@mail.gmail.com>

Morning, short reply before I go to school.

2011/5/19 a.l.e <ale.comp_06 at xox.ch>:
> hi
>>
>> 1) By default, row heights would never shrink below the size of the
>> cell content, but we could have a table (possibly row) property "Allow
>> cell frames to overflow" to allow this.
>
> i don't see a reason for it... text frames can overflow, cells should do the
> same...
> but i'd welcome two commands (which are currently missing for text frames):
> - resize frame (vertically / horizontally) to fit the text

Alright, so the code needs to be written anyway, whether it's invoked
automatically or manually.

> - delete the overflowing text (useful for lore ipsums and for text imported
> from .odt files (people tend to leave lots of empty lines at the end of
> their files...)

Okay.

>
>> 2) With this way of working, table size, both width and height, is
>> completely detached from frame size. They are not linked in any way.
>> However, we could have options similar to those for images: "Adjust
>> Frame to Table" and "Adjust Table to Frame". The latter would show the
>> same options for distributing the space as shown in the widget in the
>> mockup.
>
> yep
>
>
>> 3) If the user has picked e.g. "Proportional" for distributing
>> horizontal space, but then starts resizing columns anyway, the combo
>> in the widget could automatically go to "Manual", as a convenience.
>
> personally, i was not thinking of "proportional" as a setting for the table,
> but as a command: distribute proportionally, now!
>
> you will have to launch the command each time you resize the table.

Right, it could be done like that too. But these are details, I think
we are in good agreement of the general functionality.

> but this is another discussion: what happens when the user increases the
> width of a column?
> should the table grow? should the next column shrink? should all other
> collumns shrink?
> i wonder what is the workflow which gives the most predictable result (and
> the most tweakable...)
> i guess we have to play a bit with it...

Yes, I wonder too.

In Libre/-OpenOffice resizing a column will resize the column next to
it, but resizing a row all following rows are moved.

In InDesign (by default) following row/columns are moved when resizing
rows and columns, but with Shift pressed, resizing will resize the
row/column next to it instead.

I like the way InDesign does it. I think we should support both like they do.

Elvis


From avox at arcor.de  Fri May 20 15:24:30 2011
From: avox at arcor.de (Andreas Vox)
Date: Fri, 20 May 2011 17:24:30 +0200
Subject: [scribus-dev] Fwd: Scribus/OIF development round for 2011
References: <BANLkTin1QcBjg7_Nmr0g6dLRJ_BV-pCSJg@mail.gmail.com>
Message-ID: <99566548-DA98-4A3F-AFCD-846597B1D6E5@arcor.de>



Anfang der weitergeleiteten E-Mail:

> Von: Louis Desjardins <louis.desjardins at gmail.com>
> Datum: 20. Mai 2011 14:38:16 MESZ
> An: Craig Bradney <cbradney at scribus.info>
> Kopie: Peter Linnell <plinnell at scribus.info>, avox <avox at arcor.de>, Jean Ghali <jghali at libertysurf.fr>, Franz Schmid <Franz.Schmid at altmuehlnet.de>, Alessandro Rimoldi <ale at ideale.ch>, Alexandre Prokoudine <alexandre.prokoudine at gmail.com>, Cedric G?my <cedric.gemy at gmail.com>, claudia krummenacher <claudia at neunauge.com>
> Betreff: Re: Scribus/OIF development round for 2011
> 
> 2011/5/20 Craig Bradney <cbradney at scribus.info>
> 
> 
> 
> 
> On 19/05/2011, at 23:39, Louis Desjardins <louis.desjardins at gmail.com> wrote:
> 
>> Hi guys,
>> 
>> For the next OIF round of coding/fixing here is a list of potential candidate tasks.
>> 
>> OIF wants to help make the application more usable and thus we can decide on certain bug fixes and new or enhanced features, as long as they get in the trunk.
>> 
>> The reports are daily, thorough and compulsory. Failure to do so can lead to deny of payment.
>> 
>> The final results are expected and will be defined clearly. Thus, a functionality must be implemented, tested and in working condition at the end of the work. The code must be documented as per Scribus Team standards.
>> 
>> We can split among more coders and coders don?t necessarily need to speak French.
>> 
>> Some of the following has already been discussed during LGM 2011 with Peter, Andreas and Jean, including also Ale, Claudia and myself. I wanted Alexandre Prokoudine in the brainstorming! :) Below are his comments ! :)
>> 
>> Please add/comment
>> New Text Importer [per Jean Ghali's ideas]
>> PP vs Style Manager : get rid of the actual manager and port all settings available in the SM to the PP.
>> Create style with new context-menu with right click on text > prompt for name and keyboard shortcut.
>> Add all justifications goodies from Andreas in the paragraph style
>> Add color for drop caps [come on!] [enhancing my own idea: make the drop cap settings as flexible as a character style. Thus, font, color, shade and all the available settings for text, basically]
>> Add thin space into short words [French typography requirement]
>> Make Text runaround sane by adding "text outset" fields (no more 7 steps, this is insane)
>> Add "Text as external resource" linked to .sla file and updated just like images are [see notes from Andreas, Claudia, Ricardo, Louis]
>> This should be both ways > edit within Scribus, edit in a Text editor or wiki or whatever.
>> Style Mapping capabilities [source / target] no more blind importing of styles into a document but in fact a way to select any style(s) from the imported document and have it / them replaced by the Scribus style of your choice. Rationale: Scribus styles more capable than any WP styles + layout is done in Scribus, not in WP.
>> Fix OS X related bugs
>> Put OIF branch into trunk
>> more.... Undo/Redo enhancement (Wolfpack) ? ? just adding this now, May 19, 2011
>> even more....
>> ? add/comment
>> 
>> Please put the number of hours required to accomplish each task and bring it to completion, including the regression tests and all that is needed to make that appear in the 1.5 trunk. We need to provide Christian a working application.
>> 
>> Cheers!
>> 
>> Louis
>> 
>> /prokoudine's comments/
>> 
>> Well, if I was a Scribus developer, my TODO would look like this (from
>> higher to lower priority):
>> 
>> 1. Merge OiF branch
>> 2. Do a complete revamp of tools and their options (I'd go for
>> Inkscape-like approach)
>> 3. Improve working with text and other types of objects:
>> - easy footnotes
>> - easier text flowing around frames
>> - linked positions of objects (i.e. sidebar text object linked to a
>> paragraph and moving vertically along with the paragraph)
>> 4. Finish OpenType support (oldstyle numerals, real small caps etc.)
>> 5. Improve importers (EPS, SVG)
>> 6. That "PP vs Style Manager" thing from above, plus thin space
>> 
>> To me, the rest of the above is rather optional. I've just started
>> typesetting a book in Scribus and I'm close to ditching it in favor of
>> LaTeX simply because working with text in Scribus is so clumsey. I
>> haven't seen OiF branch in a while, but I won't take a risk of using
>> it for production.
>> 
>> I know Scribus since 2002 and after two days of nearly fulltime
>> working with 1.4.0rc3, after all the crashes, after dealing with the
>> really annoying PP I don't see how I could recommend Scribus to
>> anyone. What's worse is that I have urgent work to do (that book
>> project), and Scribus simply doesn't look like the best tool for the
>> job right now. This is rather depressing.
>> 
>> Alexandre Prokoudine
>> http://libregraphicsworld.org
> 
> 
> Two things only, as I am on iPhone:
> - Alex, please don't complain about rc3, svn has less crashes, use it, I know you know how. Most of them were related to text undo. It was too late in the process to add it but it was a critical addition for 1.4.
> - Style Manager stays
> 
> Hi Craig,
> 
> I have not expressed myself clearly enough. My fault. There is a need for a Style Manager but what I say is we do not need two dialogs doing basically the same things ? formatting text. Further down the road as new styling possibilities will rise, such as tables, pages, etc. we will need even a larger window to accomodate the editing only while we have the whole canvas to do just that. The contextual menu at right-click and dialog that shows up with name and shortcut for style seems to me the most easiest way to create a style. Re-entering data into the SM and in any event having to remember 2 layouts for those settings, the one in the PP and the one in the SM is not to ease the work of users, especially people working under pressure. This can be made all simpler and much more efficient by a small change in fact.
> 
> The day when styles become available for Pages, again an addition in the context menu > create style > name + shortcut will be the only thing needed. And this can be extended to just any style we will allow the user to create.
> 
> I have not seen one single convincing argument against it,
> 
> I hope my explanation is helping on that front!
>  
> other than it's own bugs. Estan from our gsoc tables project has proven that adding new types of styles to SM is pretty easy - his test for tables took under a day. Plus, you are suggesting adding more controls to a palette that you say is already too complicated.
> 
> We have worked a lot to make things simpler wrt the PP. Adding first line indent in there should not be too complicated.
> 
> Still, OIF sounds promising, I'd like to be more involved this year if possible, hopefully coding.
> 
> Hopefully, yes! 
> 
> Thanks for your help Louis
> 
> It's a pleasure! :) Thanks to you for making that possible!
> 
> Louis 
> 
> Craig
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110520/3026ecfa/attachment.html>

From avox at arcor.de  Fri May 20 15:25:06 2011
From: avox at arcor.de (Andreas Vox)
Date: Fri, 20 May 2011 17:25:06 +0200
Subject: [scribus-dev] Fwd: Scribus/OIF development round for 2011
References: <BANLkTim20nLset=NJ9TeY=0H-BOtWvOX9w@mail.gmail.com>
Message-ID: <B80B9B3A-6F7F-41FC-91F2-4C6C4B1F92DE@arcor.de>



Anfang der weitergeleiteten E-Mail:

> Von: Alexandre Prokoudine <alexandre.prokoudine at gmail.com>
> Datum: 20. Mai 2011 16:04:18 MESZ
> An: Craig Bradney <cbradney at scribus.info>
> Kopie: Louis Desjardins <louis.desjardins at gmail.com>, Peter Linnell <plinnell at scribus.info>, avox <avox at arcor.de>, Jean Ghali <jghali at libertysurf.fr>, Franz Schmid <Franz.Schmid at altmuehlnet.de>, Alessandro Rimoldi <ale at ideale.ch>, Cedric G?my <cedric.gemy at gmail.com>, claudia krummenacher <claudia at neunauge.com>
> Betreff: Re: Scribus/OIF development round for 2011
> 
> On Fri, May 20, 2011 at 11:17 AM, Craig Bradney wrote:
> 
>> Two things only, as I am on iPhone:
>> - Alex, please don't complain about rc3, svn has less crashes, use it, I
>> know you know how. Most of them were related to text undo. It was too late
>> in the process to add it but it was a critical addition for 1.4.
> 
> rc3 specific things are only the tip of the iceberg. I'm pretty sure I
> made it clear :)
> 
>> - Style Manager stays, I have not seen one single convincing argument
>> against it, other than it's own bugs. Estan from our gsoc tables project has
>> proven that adding new types of styles to SM is pretty easy - his test for
>> tables took under a day. Plus, you are suggesting adding more controls to a
>> palette that you say is already too complicated.
> 
> I have to say I'm torn. On one hand, managing styles should be
> convinient, and SM is OK for that. OTOH, the way new styles are
> created, edited and applied is a complete disaster. Take it from
> someone who came up with SM design :) (admittedly, the initial design
> was changed along the way, and not the way I liked)
> 
> IMO we need a complete usability research on that. E.g. we already
> discussed on-canvas formatting options before as a way to keep
> attention locus, but I know of no decisions made (not that I tracked
> it), and anyway it's just one of approaches, not part of some big
> picture.
> 
> P.S. Could we take the discussion to scribus-dev@ please? I know Louis
> unsubscribed, and I was on the verge of unsubscribing myself one time,
> but all this CC thing is really not very handy.
> 
> Alexandre Prokoudine
> http://libregraphicsworld.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110520/7355586c/attachment-0001.html>

From elvstone at gmail.com  Sun May 22 12:30:16 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Sun, 22 May 2011 14:30:16 +0200
Subject: [scribus-dev] Some notes/questions about Scribus internals and my
	project
Message-ID: <BANLkTim6ixaL9Hz6ASHFd+e24WEbYTg0gw@mail.gmail.com>

Hi all,

Today I took some time and did some browsing of the Scribus source to
try to figure out how it all fits together. Below are some notes I've
taken on some of the classes, mostly for my own sake.

Would be nice if someone could read through it and correct me if I got
something wrong. After that follows a rough plan for the first two
weeks of my project. Finally, there's a couple of specific questions
that have popped up. I'll have more questions, but these two are most
pressing right now as the project start is getting closer.

Best regards,
Elvis

Central Classes
-----------------------------
These are notes on (a few of) the central classes of Scribus. I've
excluded the styles system as it has kind of OK documentation in
styles/overview.txt.

ScribusDoc
---------------
Self-explanatory. Represents a document in Scribus. Some
responsibilities seems to be:

- get a list of objects in the document.
- get the current selection.
- manage styles and colors.
- manage grid and guides.

ScribusView
----------------
Central zoomable scrollarea showing a document. Its primary
responsibility seems to be to provide a UI for scrolling and zooming
(naturally).

PageItem and its subclasses
-------------------------------------
PageItem is the base class for all items. The base class seems to be a
bit intertwined with its subclasses, and can be queried for and
converted to its subclass type using is*() and as*() methods,
respectively (e.g. isArc(), asArc()). Page items have many
responsibilities, but most important for me seems to be that they draw
themselves to the canvas in their DrawObj_Item() method.

UndoManager
------------------
Central singleton class of the undo/redo system. Manages a map of undo
stacks, one for each document. I'm not 100% sure how the undo system
works as it does not seem to use the traditional command pattern for
undo/redo. But I understand that the undo stacks are stacks of
UndoState:s, and that multiple UndoStates can be packed into a
transaction which can be commited or rolled back. I wonder why it was
made into a singleton with several stacks (one per doc) instead of
having one undo manager per document? Also, even though it is a
singleton, pointers to the undo manager still seems to be kept in
classes such as ScribusView and ScribusMainWindow. But I guess this is
just for convenience?

General Notes
-------------------
Many of the classes such as ScribusDoc, ScribusView and PageItem have
a huge number of public member variables, many of them undocumented,
which users (and subclasses) of the classes rely on, and it's a bit
hard to tell what the responsibilities of each class really is. But I
think I have a somewhat OK view of it now.

CanvasMode
-----------------
Different modes of operations on the canvas seems to be implemented in
classes inheriting from CanvasMode. As an example, there is a canvas
mode for editing a polygon, editing a spiral et.c.

At a even higher level there seems to be the concept of "application
modes" (e.g. ScribusMainWindow::setAppMode(int)), which I'm not quite
sure what they are. Are they the same as canvas modes? In any case,
setting the "app mode" using ScribusMainWindow::setAppMode(int) seems
to be what results in a canvas mode change.

Notes on Painting of Items
-----------------------------------
Painting seems to be done in two places. The on-canvas painting of
items seems to be done by items themselves in their DrawObj_Item()
(and DrawObj_Decoration()) method. Painting of items for print output
seems to be done in the respective drawItem_*() methods in
ScPageOutput.


Now on to more specifics regarding my project. Below is a rough plan
for the first two weeks.

Week 1 - Prototype
------------------------
Begin creating a first basic PageItem_Table that has the traditional
basic table API. Something like (preliminary):

public:
  qreal width() const;
  qreal height() const;

  int rows () const;
  int columns () const;

  void insertRows(int index, int rows);
  void removeRows(int index, int rows);
  QList<qreal> &rowHeights() const;
  void setRowHeights(const QList<qreal> &rowHeights);

  void insertColumns(int index, int columns);
  void removeColumns(int index, int columns);
  QList<qreal> &columnWidths() const;
  void setColumnWidths(const QList<qreal> &columnWidths);

  void mergeCells(int row, int column, int numRows, int numCols);
  void splitCell(int row, int column, int numRows, int numCols);

private:
  /// Returns rectangle available for cell content.
  QRectF cellContentRect(int row, int column) const;

Note that the width/height API above refers to the dimensions of the
table itself, not to the table frame. The dimensions of the table
frame itself will be taken care of just like for other items.

The user should be able to insert the table the same way as current
tables are inserted. The table will not support any content yet, and
it will not use a style to draw itself but hard code cell/table
border/background.

Week 2 - Resizing of rows / columns / table
-------------------------------------------------------
Finish off the above, then add support for resizing rows, columns and
the entire table by implementing a new canvas mode.

Specific Questions
------------------------
1) Since painting of items is done in two places, in the
DrawObj_Item() method of the item itself and in ScPageOutput, does
this mean I'll have to write the painting code twice?
2) How does the current undo/redo system work? How do I implement
undoable actions? Will I need to implement one (or several?) new
UndoState classes?


From czarek at oferuje.pl  Mon May 23 05:39:01 2011
From: czarek at oferuje.pl (Cezary Grabski)
Date: Mon, 23 May 2011 07:39:01 +0200
Subject: [scribus-dev] Some notes/questions about Scribus internals and
	my project
In-Reply-To: <BANLkTim6ixaL9Hz6ASHFd+e24WEbYTg0gw@mail.gmail.com>
References: <BANLkTim6ixaL9Hz6ASHFd+e24WEbYTg0gw@mail.gmail.com>
Message-ID: <201105230739.01211.czarek@oferuje.pl>

> 2) How does the current undo/redo system work? How do I implement
> undoable actions? Will I need to implement one (or several?) new
> UndoState classes?
> 
As I made undo for text last time I can answer you what I know about undo 
system in Scribus.
It is quite simple in idea - in UndoState are saved changed parameteres of 
item before and after changing. For example for undow moving PageItem in undo 
state is saved its start position and end position. On undo start position of 
PageItem will be restored. On redo end position will be restored again.

In implementation undo can be more complicated because in undostate only 
simple variables types can be saved - numbers and strings.
So for text undo, where in undostate must be saved text with all styles 
information, I prepare function which return all that information in string by 
"saxing" (like in SLA file, when all information is in human readable strings 
in tagged fashion, lets say semi-XML manner).

BTW I think you can dont care about undo at this state of developpment.
We were live with Scribus without undo for text by years, so we can live 
without undo for tables at the beginning. Undo for tables can be added later 
when all new tables code will be "stable", even by someone else.

cezaryece


From elvstone at gmail.com  Mon May 23 10:28:14 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Mon, 23 May 2011 12:28:14 +0200
Subject: [scribus-dev] Some notes/questions about Scribus internals and
	my project
In-Reply-To: <201105230739.01211.czarek@oferuje.pl>
References: <BANLkTim6ixaL9Hz6ASHFd+e24WEbYTg0gw@mail.gmail.com>
	<201105230739.01211.czarek@oferuje.pl>
Message-ID: <BANLkTiktXTtFQP79zDqFA-eOt30vcrXi7A@mail.gmail.com>

Hi Cezary,

2011/5/23 Cezary Grabski <czarek at oferuje.pl>:
>> 2) How does the current undo/redo system work? How do I implement
>> undoable actions? Will I need to implement one (or several?) new
>> UndoState classes?
>>
> As I made undo for text last time I can answer you what I know about undo
> system in Scribus.
> It is quite simple in idea - in UndoState are saved changed parameteres of
> item before and after changing. For example for undow moving PageItem in undo
> state is saved its start position and end position. On undo start position of
> PageItem will be restored. On redo end position will be restored again.

Ah, I see. After looking a little closer I see that it is actually a
variant of the command pattern after all.

> In implementation undo can be more complicated because in undostate only
> simple variables types can be saved - numbers and strings.
> So for text undo, where in undostate must be saved text with all styles
> information, I prepare function which return all that information in string by
> "saxing" (like in SLA file, when all information is in human readable strings
> in tagged fashion, lets say semi-XML manner).

Okay, so it's serialized. Makes sense. Undo/redo really is a
complicated business :)

> BTW I think you can dont care about undo at this state of developpment.
> We were live with Scribus without undo for text by years, so we can live
> without undo for tables at the beginning. Undo for tables can be added later
> when all new tables code will be "stable", even by someone else.

Okay. I think that the table operations should not be _that_ hard to
make undoable this way. I think they will lend themselves quite well
to being encapsulated as a set of properties in an undo state. But
we'll see whether I'll have time for undo/redo then.

BTW, I _very_ much appreciate how well commented/documented the
undo/redo code is. Good job there!

Elvis


From avox at arcor.de  Mon May 23 12:14:21 2011
From: avox at arcor.de (Andreas Vox)
Date: Mon, 23 May 2011 14:14:21 +0200
Subject: [scribus-dev] Some notes/questions about Scribus internals and
	my project
In-Reply-To: <BANLkTiktXTtFQP79zDqFA-eOt30vcrXi7A@mail.gmail.com>
References: <BANLkTim6ixaL9Hz6ASHFd+e24WEbYTg0gw@mail.gmail.com>
	<201105230739.01211.czarek@oferuje.pl>
	<BANLkTiktXTtFQP79zDqFA-eOt30vcrXi7A@mail.gmail.com>
Message-ID: <000b01cc1942$f2c75f30$d8561d90$@de>

Hi Elvis!

The class UndoState acts more or less as a Command pattern. SimpleState is
more or less a "one-size-fits-all" kind of Command pattern implementation.

We had discussions about undo/redo with one of the GSoC applicants and we
agreed that Scribus should use less SimpleState and more specific subclasses
of UndoState. IIRC it's not necessary to implement the restore method in the
UndoObject in this case.

/Andreas

> -----Urspr?ngliche Nachricht-----
> Von: Elvis Stansvik [mailto:elvstone at gmail.com]
> Gesendet: Montag, 23. Mai 2011 12:28
> An: Scribus Development Mailing List
> Betreff: Re: [scribus-dev] Some notes/questions about Scribus internals
> and my project
> 
> Hi Cezary,
> 
> 2011/5/23 Cezary Grabski <czarek at oferuje.pl>:
> >> 2) How does the current undo/redo system work? How do I implement
> >> undoable actions? Will I need to implement one (or several?) new
> >> UndoState classes?
> >>
> > As I made undo for text last time I can answer you what I know about
> undo
> > system in Scribus.
> > It is quite simple in idea - in UndoState are saved changed
> parameteres of
> > item before and after changing. For example for undow moving PageItem
> in undo
> > state is saved its start position and end position. On undo start
> position of
> > PageItem will be restored. On redo end position will be restored
> again.
> 
> Ah, I see. After looking a little closer I see that it is actually a
> variant of the command pattern after all.
> 
> > In implementation undo can be more complicated because in undostate
> only
> > simple variables types can be saved - numbers and strings.
> > So for text undo, where in undostate must be saved text with all
> styles
> > information, I prepare function which return all that information in
> string by
> > "saxing" (like in SLA file, when all information is in human readable
> strings
> > in tagged fashion, lets say semi-XML manner).
> 
> Okay, so it's serialized. Makes sense. Undo/redo really is a
> complicated business :)
> 
> > BTW I think you can dont care about undo at this state of
> developpment.
> > We were live with Scribus without undo for text by years, so we can
> live
> > without undo for tables at the beginning. Undo for tables can be
> added later
> > when all new tables code will be "stable", even by someone else.
> 
> Okay. I think that the table operations should not be _that_ hard to
> make undoable this way. I think they will lend themselves quite well
> to being encapsulated as a set of properties in an undo state. But
> we'll see whether I'll have time for undo/redo then.
> 
> BTW, I _very_ much appreciate how well commented/documented the
> undo/redo code is. Good job there!
> 
> Elvis
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev



From avox at arcor.de  Mon May 23 12:29:43 2011
From: avox at arcor.de (Andreas Vox)
Date: Mon, 23 May 2011 14:29:43 +0200
Subject: [scribus-dev] Some notes/questions about Scribus internals and
	my project
In-Reply-To: <BANLkTim6ixaL9Hz6ASHFd+e24WEbYTg0gw@mail.gmail.com>
References: <BANLkTim6ixaL9Hz6ASHFd+e24WEbYTg0gw@mail.gmail.com>
Message-ID: <000c01cc1945$18a66e60$49f34b20$@de>

Hi Elvis!

Good observations for the most part. Some comments inline:

> -----Urspr?ngliche Nachricht-----
> Von: Elvis Stansvik [mailto:elvstone at gmail.com]
> Gesendet: Sonntag, 22. Mai 2011 14:30
> An: Scribus Development Mailing List
> Betreff: [scribus-dev] Some notes/questions about Scribus internals and
> my project
> 
> Hi all,
> 
> Today I took some time and did some browsing of the Scribus source to
> try to figure out how it all fits together. Below are some notes I've
> taken on some of the classes, mostly for my own sake.
> 
> Would be nice if someone could read through it and correct me if I got
> something wrong. After that follows a rough plan for the first two
> weeks of my project. Finally, there's a couple of specific questions
> that have popped up. I'll have more questions, but these two are most
> pressing right now as the project start is getting closer.
> 
> Best regards,
> Elvis
> 
> Central Classes
> -----------------------------
> These are notes on (a few of) the central classes of Scribus. I've
> excluded the styles system as it has kind of OK documentation in
> styles/overview.txt.
> 
> ScribusDoc
> ---------------
> Self-explanatory. Represents a document in Scribus. Some
> responsibilities seems to be:
> 
> - get a list of objects in the document.
> - get the current selection.
> - manage styles and colors.
> - manage grid and guides.
> 
> ScribusView
> ----------------
> Central zoomable scrollarea showing a document. Its primary
> responsibility seems to be to provide a UI for scrolling and zooming
> (naturally).
> 
> PageItem and its subclasses
> -------------------------------------
> PageItem is the base class for all items. The base class seems to be a
> bit intertwined with its subclasses, and can be queried for and
> converted to its subclass type using is*() and as*() methods,
> respectively (e.g. isArc(), asArc()). Page items have many
> responsibilities, but most important for me seems to be that they draw
> themselves to the canvas in their DrawObj_Item() method.
> 
> UndoManager
> ------------------
> Central singleton class of the undo/redo system. Manages a map of undo
> stacks, one for each document. I'm not 100% sure how the undo system
> works as it does not seem to use the traditional command pattern for
> undo/redo. But I understand that the undo stacks are stacks of
> UndoState:s, and that multiple UndoStates can be packed into a
> transaction which can be commited or rolled back. I wonder why it was
> made into a singleton with several stacks (one per doc) instead of
> having one undo manager per document? 

There may be different documents, but we only have one UndoAction linked to
the UI.
So at one point we need to decide which document to use anyway.

> Also, even though it is a
> singleton, pointers to the undo manager still seems to be kept in
> classes such as ScribusView and ScribusMainWindow. But I guess this is
> just for convenience?

I guess you are right (for some given value of "convenience"). Feel free to
use the singleton instead.

> 
> General Notes
> -------------------
> Many of the classes such as ScribusDoc, ScribusView and PageItem have
> a huge number of public member variables, many of them undocumented,
> which users (and subclasses) of the classes rely on, and it's a bit
> hard to tell what the responsibilities of each class really is. But I
> think I have a somewhat OK view of it now.

Yes, isn't that ugly? :-) It's on the roadmap for refactoring.

> 
> CanvasMode
> -----------------
> Different modes of operations on the canvas seems to be implemented in
> classes inheriting from CanvasMode. As an example, there is a canvas
> mode for editing a polygon, editing a spiral et.c.
> 
> At a even higher level there seems to be the concept of "application
> modes" (e.g. ScribusMainWindow::setAppMode(int)), which I'm not quite
> sure what they are. Are they the same as canvas modes? In any case,
> setting the "app mode" using ScribusMainWindow::setAppMode(int) seems
> to be what results in a canvas mode change.

In the beginning Scribus just had application modes and some huge switches
and
if-then-else constructs to do the right thing at the right time. I
refactored
all that code into CanvasModes (correspond to application modes) and
CanvasGestures
(correspond to submodes, ie. Scribus returns to the CanvasMode it was in
before the
CanvasGesture was started. Gestures could be stacked).

This structure made it possible to concentrate on a single user interaction
when
implementing mouse event code.

> 
> Notes on Painting of Items
> -----------------------------------
> Painting seems to be done in two places. The on-canvas painting of
> items seems to be done by items themselves in their DrawObj_Item()
> (and DrawObj_Decoration()) method. Painting of items for print output
> seems to be done in the respective drawItem_*() methods in
> ScPageOutput.

IIRC ScPageOutput is only used for printing in Scribus. There's additional
code
in pdflib_core.cpp and pslib.cpp (Yes, 4 versions of the same code. That's
another refactoring on the roadmap!) 

> 
> 
> Now on to more specifics regarding my project. Below is a rough plan
> for the first two weeks.
> 
> Week 1 - Prototype
> ------------------------
> Begin creating a first basic PageItem_Table that has the traditional
> basic table API. Something like (preliminary):
> 
> public:
>   qreal width() const;
>   qreal height() const;
> 
>   int rows () const;
>   int columns () const;
> 
>   void insertRows(int index, int rows);
>   void removeRows(int index, int rows);
>   QList<qreal> &rowHeights() const;
>   void setRowHeights(const QList<qreal> &rowHeights);
> 
>   void insertColumns(int index, int columns);
>   void removeColumns(int index, int columns);
>   QList<qreal> &columnWidths() const;
>   void setColumnWidths(const QList<qreal> &columnWidths);
> 
>   void mergeCells(int row, int column, int numRows, int numCols);
>   void splitCell(int row, int column, int numRows, int numCols);
> 
> private:
>   /// Returns rectangle available for cell content.
>   QRectF cellContentRect(int row, int column) const;
>

I don't see any API to acces the content of a cell?

> Note that the width/height API above refers to the dimensions of the
> table itself, not to the table frame. The dimensions of the table
> frame itself will be taken care of just like for other items.
> 
> The user should be able to insert the table the same way as current
> tables are inserted. The table will not support any content yet, and
> it will not use a style to draw itself but hard code cell/table
> border/background.
> 
> Week 2 - Resizing of rows / columns / table
> -------------------------------------------------------
> Finish off the above, then add support for resizing rows, columns and
> the entire table by implementing a new canvas mode.
> 
> Specific Questions
> ------------------------
> 1) Since painting of items is done in two places, in the
> DrawObj_Item() method of the item itself and in ScPageOutput, does
> this mean I'll have to write the painting code twice?

Or 4 times, see above. We'll have to discuss that (maybe find a way to
reuse existing text code or maybe we can do the refactoring earlier so
that DrawObj_Item(ScPainter) is enough).

> 2) How does the current undo/redo system work? How do I implement
> undoable actions? Will I need to implement one (or several?) new
> UndoState classes?

Yes, that's what I'd recommend. See my other post.

/Andreas



From rajeev.sebastian at gmail.com  Mon May 23 14:28:49 2011
From: rajeev.sebastian at gmail.com (Rajeev J Sebastian)
Date: Mon, 23 May 2011 19:58:49 +0530
Subject: [scribus-dev] Fwd: Scribus/OIF development round for 2011
In-Reply-To: <B80B9B3A-6F7F-41FC-91F2-4C6C4B1F92DE@arcor.de>
References: <BANLkTim20nLset=NJ9TeY=0H-BOtWvOX9w@mail.gmail.com>
	<B80B9B3A-6F7F-41FC-91F2-4C6C4B1F92DE@arcor.de>
Message-ID: <BANLkTi=o7YOdGezjZXMJzUwRdR_dMYR+=A@mail.gmail.com>

Where is the latest OIF code? The one on the svn seems to be
incomplete/not working.

Regards
Rajeev J Sebastian

2011/5/20 Andreas Vox <avox at arcor.de>:
>
>
> Anfang der weitergeleiteten E-Mail:
>
> Von: Alexandre Prokoudine <alexandre.prokoudine at gmail.com>
> Datum: 20. Mai 2011 16:04:18 MESZ
> An: Craig Bradney <cbradney at scribus.info>
> Kopie: Louis Desjardins <louis.desjardins at gmail.com>, Peter Linnell
> <plinnell at scribus.info>, avox <avox at arcor.de>, Jean Ghali
> <jghali at libertysurf.fr>, Franz Schmid <Franz.Schmid at altmuehlnet.de>,
> Alessandro Rimoldi <ale at ideale.ch>, Cedric G?my <cedric.gemy at gmail.com>,
> claudia krummenacher <claudia at neunauge.com>
> Betreff: Re: Scribus/OIF development round for 2011
>
> On Fri, May 20, 2011 at 11:17 AM, Craig Bradney wrote:
>
> Two things only, as I am on iPhone:
>
> - Alex, please don't complain about rc3, svn has less crashes, use it, I
>
> know you know how. Most of them were related to text undo. It was too late
>
> in the process to add it but it was a critical addition for 1.4.
>
> rc3 specific things are only the tip of the iceberg. I'm pretty sure I
> made it clear :)
>
> - Style Manager stays, I have not seen one single convincing argument
>
> against it, other than it's own bugs. Estan from our gsoc tables project has
>
> proven that adding new types of styles to SM is pretty easy - his test for
>
> tables took under a day. Plus, you are suggesting adding more controls to a
>
> palette that you say is already too complicated.
>
> I have to say I'm torn. On one hand, managing styles should be
> convinient, and SM is OK for that. OTOH, the way new styles are
> created, edited and applied is a complete disaster. Take it from
> someone who came up with SM design :) (admittedly, the initial design
> was changed along the way, and not the way I liked)
>
> IMO we need a complete usability research on that. E.g. we already
> discussed on-canvas formatting options before as a way to keep
> attention locus, but I know of no decisions made (not that I tracked
> it), and anyway it's just one of approaches, not part of some big
> picture.
>
> P.S. Could we take the discussion to scribus-dev@ please? I know Louis
> unsubscribed, and I was on the verge of unsubscribing myself one time,
> but all this CC thing is really not very handy.
>
> Alexandre Prokoudine
> http://libregraphicsworld.org
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>


From elvstone at gmail.com  Mon May 23 14:30:57 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Mon, 23 May 2011 16:30:57 +0200
Subject: [scribus-dev] Some notes/questions about Scribus internals and
	my project
In-Reply-To: <000c01cc1945$18a66e60$49f34b20$@de>
References: <BANLkTim6ixaL9Hz6ASHFd+e24WEbYTg0gw@mail.gmail.com>
	<000c01cc1945$18a66e60$49f34b20$@de>
Message-ID: <BANLkTin30Nv9kA5RV1cHVvaFomXs0PHRxQ@mail.gmail.com>

Hi Andreas,

2011/5/23 Andreas Vox <avox at arcor.de>:
> Hi Elvis!
>
> Good observations for the most part. Some comments inline:
>
> ...
>
> There may be different documents, but we only have one UndoAction linked to
> the UI.
> So at one point we need to decide which document to use anyway.

I see. Makes sense.

>> Also, even though it is a
>> singleton, pointers to the undo manager still seems to be kept in
>> classes such as ScribusView and ScribusMainWindow. But I guess this is
>> just for convenience?
>
> I guess you are right (for some given value of "convenience"). Feel free to
> use the singleton instead.

Okay.

>> General Notes
>> -------------------
>> Many of the classes such as ScribusDoc, ScribusView and PageItem have
>> a huge number of public member variables, many of them undocumented,
>> which users (and subclasses) of the classes rely on, and it's a bit
>> hard to tell what the responsibilities of each class really is. But I
>> think I have a somewhat OK view of it now.
>
> Yes, isn't that ugly? :-) It's on the roadmap for refactoring.

Well I didn't want to be the one to say it, but yes ;) Good to hear
that a refactor is on the map. Anyway, it's completely understandable
for a large code base to grow some warts over time.

>> CanvasMode
>> -----------------
>> Different modes of operations on the canvas seems to be implemented in
>> classes inheriting from CanvasMode. As an example, there is a canvas
>> mode for editing a polygon, editing a spiral et.c.
>>
>> At a even higher level there seems to be the concept of "application
>> modes" (e.g. ScribusMainWindow::setAppMode(int)), which I'm not quite
>> sure what they are. Are they the same as canvas modes? In any case,
>> setting the "app mode" using ScribusMainWindow::setAppMode(int) seems
>> to be what results in a canvas mode change.
>
> In the beginning Scribus just had application modes and some huge switches
> and
> if-then-else constructs to do the right thing at the right time. I
> refactored
> all that code into CanvasModes (correspond to application modes) and
> CanvasGestures
> (correspond to submodes, ie. Scribus returns to the CanvasMode it was in
> before the
> CanvasGesture was started. Gestures could be stacked).
>
> This structure made it possible to concentrate on a single user interaction
> when
> implementing mouse event code.

Yes, I got the feeling that the canvas mode was a solution to an
earlier problem. Thanks for clarifying.

>> Notes on Painting of Items
>> -----------------------------------
>> Painting seems to be done in two places. The on-canvas painting of
>> items seems to be done by items themselves in their DrawObj_Item()
>> (and DrawObj_Decoration()) method. Painting of items for print output
>> seems to be done in the respective drawItem_*() methods in
>> ScPageOutput.
>
> IIRC ScPageOutput is only used for printing in Scribus. There's additional
> code
> in pdflib_core.cpp and pslib.cpp (Yes, 4 versions of the same code. That's
> another refactoring on the roadmap!)

Yikes. But OK, just guess we'll have to deal with that.

>> Now on to more specifics regarding my project. Below is a rough plan
>> for the first two weeks.
>>
>> Week 1 - Prototype
>> ------------------------
>> Begin creating a first basic PageItem_Table that has the traditional
>> basic table API. Something like (preliminary):
>>
>> public:
>> ? qreal width() const;
>> ? qreal height() const;
>>
>> ? int rows () const;
>> ? int columns () const;
>>
>> ? void insertRows(int index, int rows);
>> ? void removeRows(int index, int rows);
>> ? QList<qreal> &rowHeights() const;
>> ? void setRowHeights(const QList<qreal> &rowHeights);
>>
>> ? void insertColumns(int index, int columns);
>> ? void removeColumns(int index, int columns);
>> ? QList<qreal> &columnWidths() const;
>> ? void setColumnWidths(const QList<qreal> &columnWidths);
>>
>> ? void mergeCells(int row, int column, int numRows, int numCols);
>> ? void splitCell(int row, int column, int numRows, int numCols);
>>
>> private:
>> ? /// Returns rectangle available for cell content.
>> ? QRectF cellContentRect(int row, int column) const;
>>
>
> I don't see any API to acces the content of a cell?

See further down: "The table will not support any content yet, [...]".
This is for the first week. Baby steps you know. But of course there
will be an API for querying the content of the table, once it's
available, and also a lot of other API that isn't in the above list.

That said, I've already implemented large parts of the API above, so
maybe the schedule will have to be revised :)

>> ...
>>
>> Specific Questions
>> ------------------------
>> 1) Since painting of items is done in two places, in the
>> DrawObj_Item() method of the item itself and in ScPageOutput, does
>> this mean I'll have to write the painting code twice?
>
> Or 4 times, see above. We'll have to discuss that (maybe find a way to
> reuse existing text code or maybe we can do the refactoring earlier so
> that DrawObj_Item(ScPainter) is enough).

Yes, I naturally welcome any solutions that makes me not have to write
essentially the same painting code 4 times, but we'll discuss that
later. The painting code will grow over time, and at this early stage
I'll stick do doing it in DrawObj_Item method.

>> 2) How does the current undo/redo system work? How do I implement
>> undoable actions? Will I need to implement one (or several?) new
>> UndoState classes?
>
> Yes, that's what I'd recommend. See my other post.

Okay.

Thanks for your reply Andreas.

Regards,
Elvis


From alexandre.prokoudine at gmail.com  Mon May 23 14:37:58 2011
From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine)
Date: Mon, 23 May 2011 18:37:58 +0400
Subject: [scribus-dev] Fwd: Scribus/OIF development round for 2011
In-Reply-To: <BANLkTi=o7YOdGezjZXMJzUwRdR_dMYR+=A@mail.gmail.com>
References: <BANLkTim20nLset=NJ9TeY=0H-BOtWvOX9w@mail.gmail.com>
	<B80B9B3A-6F7F-41FC-91F2-4C6C4B1F92DE@arcor.de>
	<BANLkTi=o7YOdGezjZXMJzUwRdR_dMYR+=A@mail.gmail.com>
Message-ID: <BANLkTinLC1vTAV2frFt8u68LNGbCJ0XzxQ@mail.gmail.com>

On Mon, May 23, 2011 at 6:28 PM, Rajeev J Sebastian
<rajeev.sebastian at gmail.com> wrote:
> Where is the latest OIF code? The one on the svn seems to be
> incomplete/not working.

svn co svn://scribus.net/branches/ScribusOIF

Last Changed Date: 2011-05-13 19:17:16 +0400 (Fri, 13 May 2011)

Alexandre Prokoudine
http://libregraphicsworld.org


From gpittman at iglou.com  Mon May 23 15:53:53 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Mon, 23 May 2011 11:53:53 -0400
Subject: [scribus-dev] Fwd: Scribus/OIF development round for 2011
In-Reply-To: <BANLkTinLC1vTAV2frFt8u68LNGbCJ0XzxQ@mail.gmail.com>
References: <BANLkTim20nLset=NJ9TeY=0H-BOtWvOX9w@mail.gmail.com>	<B80B9B3A-6F7F-41FC-91F2-4C6C4B1F92DE@arcor.de>	<BANLkTi=o7YOdGezjZXMJzUwRdR_dMYR+=A@mail.gmail.com>
	<BANLkTinLC1vTAV2frFt8u68LNGbCJ0XzxQ@mail.gmail.com>
Message-ID: <4DDA8311.9090702@iglou.com>

On 05/23/2011 10:37 AM, Alexandre Prokoudine wrote:
> On Mon, May 23, 2011 at 6:28 PM, Rajeev J Sebastian
> <rajeev.sebastian at gmail.com>  wrote:
>> Where is the latest OIF code? The one on the svn seems to be
>> incomplete/not working.
>
> svn co svn://scribus.net/branches/ScribusOIF
>
> Last Changed Date: 2011-05-13 19:17:16 +0400 (Fri, 13 May 2011)
>
Yes, I too have yet to see an OIF that works in an acceptable fashion.

Greg


From rajeev.sebastian at gmail.com  Mon May 23 17:19:07 2011
From: rajeev.sebastian at gmail.com (Rajeev J Sebastian)
Date: Mon, 23 May 2011 22:49:07 +0530
Subject: [scribus-dev] Fwd: Scribus/OIF development round for 2011
In-Reply-To: <BANLkTinLC1vTAV2frFt8u68LNGbCJ0XzxQ@mail.gmail.com>
References: <BANLkTim20nLset=NJ9TeY=0H-BOtWvOX9w@mail.gmail.com>
	<B80B9B3A-6F7F-41FC-91F2-4C6C4B1F92DE@arcor.de>
	<BANLkTi=o7YOdGezjZXMJzUwRdR_dMYR+=A@mail.gmail.com>
	<BANLkTinLC1vTAV2frFt8u68LNGbCJ0XzxQ@mail.gmail.com>
Message-ID: <BANLkTinF=v66gzLgSRaJnjoaZhuH-0VHpg@mail.gmail.com>

So that's the canonical development VCS for OIF? In this branch for
some reason, text like "Hello" is rendered one character per line,
i.e., "H", "e", etc are each on its own line. Is this expected?

Regards
Rajeev J Sebastian

On Mon, May 23, 2011 at 8:07 PM, Alexandre Prokoudine
<alexandre.prokoudine at gmail.com> wrote:
> On Mon, May 23, 2011 at 6:28 PM, Rajeev J Sebastian
> <rajeev.sebastian at gmail.com> wrote:
>> Where is the latest OIF code? The one on the svn seems to be
>> incomplete/not working.
>
> svn co svn://scribus.net/branches/ScribusOIF
>
> Last Changed Date: 2011-05-13 19:17:16 +0400 (Fri, 13 May 2011)
>
> Alexandre Prokoudine
> http://libregraphicsworld.org
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From jghali at libertysurf.fr  Mon May 23 17:29:19 2011
From: jghali at libertysurf.fr (jghali at libertysurf.fr)
Date: Mon, 23 May 2011 19:29:19 +0200 (CEST)
Subject: [scribus-dev] Fwd: Scribus/OIF development round for 2011
In-Reply-To: <BANLkTinF=v66gzLgSRaJnjoaZhuH-0VHpg@mail.gmail.com>
Message-ID: <1067578728.1454761306171759754.JavaMail.root@zimbra45-e7.priv.proxad.net>


----- Mail Original -----
De: "Rajeev J Sebastian" <rajeev.sebastian at gmail.com>
?: "Scribus Development Mailing List" <scribus-dev at lists.scribus.net>
Envoy?: Lundi 23 Mai 2011 19h19:07 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [scribus-dev] Fwd: Scribus/OIF development round for 2011

So that's the canonical development VCS for OIF? In this branch for
some reason, text like "Hello" is rendered one character per line,
i.e., "H", "e", etc are each on its own line. Is this expected?


Hi Rajeev,

Work in OIF branch is far from being finished and its state can not even be qualified as "alpha". So do not expect it to be usable the same way trunk is.

Jean


From rajeev.sebastian at gmail.com  Mon May 23 18:12:13 2011
From: rajeev.sebastian at gmail.com (Rajeev J Sebastian)
Date: Mon, 23 May 2011 23:42:13 +0530
Subject: [scribus-dev] Fwd: Scribus/OIF development round for 2011
In-Reply-To: <1067578728.1454761306171759754.JavaMail.root@zimbra45-e7.priv.proxad.net>
References: <BANLkTinF=v66gzLgSRaJnjoaZhuH-0VHpg@mail.gmail.com>
	<1067578728.1454761306171759754.JavaMail.root@zimbra45-e7.priv.proxad.net>
Message-ID: <BANLkTi=-RUZnOzDuv759JCiobzwDOdVM2A@mail.gmail.com>

On Mon, May 23, 2011 at 10:59 PM,  <jghali at libertysurf.fr> wrote:
>
> ----- Mail Original -----
> De: "Rajeev J Sebastian" <rajeev.sebastian at gmail.com>
> ?: "Scribus Development Mailing List" <scribus-dev at lists.scribus.net>
> Envoy?: Lundi 23 Mai 2011 19h19:07 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
> Objet: Re: [scribus-dev] Fwd: Scribus/OIF development round for 2011
>
> So that's the canonical development VCS for OIF? In this branch for
> some reason, text like "Hello" is rendered one character per line,
> i.e., "H", "e", etc are each on its own line. Is this expected?
>
>
> Hi Rajeev,
>
> Work in OIF branch is far from being finished and its state can not even be qualified as "alpha". So do not expect it to be usable the same way trunk is.

Hi Jean,

Yes I understand and appreciate all of your work on it. I was just
wondering whether I had the right code or not.

Regards
Rajeev J Sebastian


From cbradney at zip.com.au  Mon May 23 20:06:42 2011
From: cbradney at zip.com.au (Craig Bradney)
Date: Mon, 23 May 2011 22:06:42 +0200
Subject: [scribus-dev] Some notes/questions about Scribus internals and
 my project
In-Reply-To: <BANLkTin30Nv9kA5RV1cHVvaFomXs0PHRxQ@mail.gmail.com>
References: <BANLkTim6ixaL9Hz6ASHFd+e24WEbYTg0gw@mail.gmail.com>	<000c01cc1945$18a66e60$49f34b20$@de>
	<BANLkTin30Nv9kA5RV1cHVvaFomXs0PHRxQ@mail.gmail.com>
Message-ID: <4DDABE52.9050109@zip.com.au>


>> Yes, isn't that ugly? :-) It's on the roadmap for refactoring.
> Well I didn't want to be the one to say it, but yes ;) Good to hear
> that a refactor is on the map. Anyway, it's completely understandable
> for a large code base to grow some warts over time.
>

I'd suggest making a note of those warts you find/we mention on a new
wiki page - there are a lot, and implementing new functionality is a
good way to find them.

With a decent list, we can either kill them as you implement, or come
back later. Noting in your changes a bug number to relate to would be
good, or just implementing without the warts would be best, if at all
possible, but may not be given the rest of the codebase.

Craig




From cbradney at scribus.info  Mon May 23 20:52:05 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Mon, 23 May 2011 22:52:05 +0200
Subject: [scribus-dev] Fwd: r16620 by craig - #9912: Apply patch to assist
 with cursor movement between linked frames
Message-ID: <4DDAC8F5.8050706@scribus.info>

Hi

Jean and I talked about this patch the other night and agreed to push it
to SVN as it provides a better experience than current 1.4.0svn does.

Please test for bugs/crashes.. its late in 1.4.0..

Thanks to Cezary!

Craig


Author: craig
Date: Mon May 23 20:24:54 2011
New Revision: 16620

URL: http://scribus.info/websvn/listing.php?repname=Scribus&sc=1&rev=16620
Log:
#9912: Apply patch to assist with cursor movement between linked frames

Modified:
    branches/Version135/Scribus/scribus/pageitem.cpp
    branches/Version135/Scribus/scribus/pageitem.h
    branches/Version135/Scribus/scribus/pageitem_textframe.cpp
    branches/Version135/Scribus/scribus/pageitem_textframe.h


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110523/9f4f3191/attachment.bin>

From louis.desjardins at gmail.com  Tue May 24 03:36:20 2011
From: louis.desjardins at gmail.com (Louis Desjardins)
Date: Mon, 23 May 2011 23:36:20 -0400
Subject: [scribus-dev] Fwd: r16620 by craig - #9912: Apply patch to
 assist with cursor movement between linked frames
In-Reply-To: <4DDAC8F5.8050706@scribus.info>
References: <4DDAC8F5.8050706@scribus.info>
Message-ID: <BANLkTi=tvu_FcKMwopqY9_0h0-KgHb+W3Q@mail.gmail.com>

Hi,

I get this error message when I click on the url:
"File "include/config.php" does not exist, please create one. The example
file "include/distconfig.php" may be copied and modified as needed."

Louis

2011/5/23 Craig Bradney <cbradney at scribus.info>

> Hi
>
> Jean and I talked about this patch the other night and agreed to push it
> to SVN as it provides a better experience than current 1.4.0svn does.
>
> Please test for bugs/crashes.. its late in 1.4.0..
>
> Thanks to Cezary!
>
> Craig
>
>
> Author: craig
> Date: Mon May 23 20:24:54 2011
> New Revision: 16620
>
> URL: http://scribus.info/websvn/listing.php?repname=Scribus&sc=1&rev=16620
> Log:
> #9912: Apply patch to assist with cursor movement between linked frames
>
> Modified:
>    branches/Version135/Scribus/scribus/pageitem.cpp
>    branches/Version135/Scribus/scribus/pageitem.h
>    branches/Version135/Scribus/scribus/pageitem_textframe.cpp
>    branches/Version135/Scribus/scribus/pageitem_textframe.h
>
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110523/8e9a1486/attachment-0001.html>

From louis.desjardins at gmail.com  Tue May 24 03:36:20 2011
From: louis.desjardins at gmail.com (Louis Desjardins)
Date: Mon, 23 May 2011 23:36:20 -0400
Subject: [scribus-dev] Fwd: r16620 by craig - #9912: Apply patch to
 assist with cursor movement between linked frames
In-Reply-To: <4DDAC8F5.8050706@scribus.info>
References: <4DDAC8F5.8050706@scribus.info>
Message-ID: <BANLkTi=tvu_FcKMwopqY9_0h0-KgHb+W3Q@mail.gmail.com>

Hi,

I get this error message when I click on the url:
"File "include/config.php" does not exist, please create one. The example
file "include/distconfig.php" may be copied and modified as needed."

Louis

2011/5/23 Craig Bradney <cbradney at scribus.info>

> Hi
>
> Jean and I talked about this patch the other night and agreed to push it
> to SVN as it provides a better experience than current 1.4.0svn does.
>
> Please test for bugs/crashes.. its late in 1.4.0..
>
> Thanks to Cezary!
>
> Craig
>
>
> Author: craig
> Date: Mon May 23 20:24:54 2011
> New Revision: 16620
>
> URL: http://scribus.info/websvn/listing.php?repname=Scribus&sc=1&rev=16620
> Log:
> #9912: Apply patch to assist with cursor movement between linked frames
>
> Modified:
>    branches/Version135/Scribus/scribus/pageitem.cpp
>    branches/Version135/Scribus/scribus/pageitem.h
>    branches/Version135/Scribus/scribus/pageitem_textframe.cpp
>    branches/Version135/Scribus/scribus/pageitem_textframe.h
>
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110523/8e9a1486/attachment-0002.html>

From cbradney at scribus.info  Tue May 24 06:02:56 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Tue, 24 May 2011 08:02:56 +0200
Subject: [scribus-dev] Fwd: r16620 by craig - #9912: Apply patch to
	assist with cursor movement between linked frames
In-Reply-To: <BANLkTi=tvu_FcKMwopqY9_0h0-KgHb+W3Q@mail.gmail.com>
References: <4DDAC8F5.8050706@scribus.info>
	<BANLkTi=tvu_FcKMwopqY9_0h0-KgHb+W3Q@mail.gmail.com>
Message-ID: <44EDAB5C-F617-419D-8004-3620C2AB7AA7@scribus.info>





On 24/05/2011, at 5:36, Louis Desjardins <louis.desjardins at gmail.com> wrote:

> Hi,
> 
> I get this error message when I click on the url:
> "File "include/config.php" does not exist, please create one. The example file "include/distconfig.php" may be copied and modified as needed."
> 
> Louis
> 
> 2011/5/23 Craig Bradney <cbradney at scribus.info>
> Hi
> 
> Jean and I talked about this patch the other night and agreed to push it
> to SVN as it provides a better experience than current 1.4.0svn does.
> 
> Please test for bugs/crashes.. its late in 1.4.0..
> 
> Thanks to Cezary!
> 
> Craig
> 
> 
> Author: craig
> Date: Mon May 23 20:24:54 2011
> New Revision: 16620
>    


Don't worry about the link, that's just the code changes.

Malex can you please check the websvn config though?

Tnx
Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110524/42406c45/attachment.html>

From cbradney at scribus.info  Tue May 24 06:02:56 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Tue, 24 May 2011 08:02:56 +0200
Subject: [scribus-dev] Fwd: r16620 by craig - #9912: Apply patch to
	assist with cursor movement between linked frames
In-Reply-To: <BANLkTi=tvu_FcKMwopqY9_0h0-KgHb+W3Q@mail.gmail.com>
References: <4DDAC8F5.8050706@scribus.info>
	<BANLkTi=tvu_FcKMwopqY9_0h0-KgHb+W3Q@mail.gmail.com>
Message-ID: <44EDAB5C-F617-419D-8004-3620C2AB7AA7@scribus.info>





On 24/05/2011, at 5:36, Louis Desjardins <louis.desjardins at gmail.com> wrote:

> Hi,
> 
> I get this error message when I click on the url:
> "File "include/config.php" does not exist, please create one. The example file "include/distconfig.php" may be copied and modified as needed."
> 
> Louis
> 
> 2011/5/23 Craig Bradney <cbradney at scribus.info>
> Hi
> 
> Jean and I talked about this patch the other night and agreed to push it
> to SVN as it provides a better experience than current 1.4.0svn does.
> 
> Please test for bugs/crashes.. its late in 1.4.0..
> 
> Thanks to Cezary!
> 
> Craig
> 
> 
> Author: craig
> Date: Mon May 23 20:24:54 2011
> New Revision: 16620
>    


Don't worry about the link, that's just the code changes.

Malex can you please check the websvn config though?

Tnx
Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110524/42406c45/attachment-0001.html>

From gpittman at iglou.com  Tue May 24 16:05:14 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Tue, 24 May 2011 12:05:14 -0400
Subject: [scribus-dev] Fwd: r16620 by craig - #9912: Apply patch
 to	assist with cursor movement between linked frames
In-Reply-To: <44EDAB5C-F617-419D-8004-3620C2AB7AA7@scribus.info>
References: <4DDAC8F5.8050706@scribus.info>	<BANLkTi=tvu_FcKMwopqY9_0h0-KgHb+W3Q@mail.gmail.com>
	<44EDAB5C-F617-419D-8004-3620C2AB7AA7@scribus.info>
Message-ID: <4DDBD73A.3080108@iglou.com>

On 05/24/2011 02:02 AM, Craig Bradney wrote:
>
>
> Don't worry about the link, that's just the code changes.
>
> Malex can you please check the websvn config though?

patch seems to work well, though I have to say I have a limited need for 
this.

Greg


From cbradney at scribus.info  Tue May 24 20:56:38 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Tue, 24 May 2011 22:56:38 +0200
Subject: [scribus-dev] 1.4.0 RC4
Message-ID: <4DDC1B86.1000708@scribus.info>

Hi All

Jean and I agree that we should release an RC4. We have not fixed many
bugs of late, however a few were fixed since RC3 and a few regular
issues reported are exactly those that were fixed since RC3.

mrdocs, do you have time to do the tag/release work this coming weekend?
I'll be in Paris until Saturday night but can kick off builds on Sunday
at a minimum for OSX (so don't wait for me).

Thanks
Craig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110524/e13d7e6c/attachment.bin>

From elvstone at gmail.com  Wed May 25 21:48:03 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 25 May 2011 23:48:03 +0200
Subject: [scribus-dev] Possibly some (slightly!) bad news
Message-ID: <BANLkTikMoqNJLuy1tdFkHCws65sGibLYtA@mail.gmail.com>

Hi all,

Yesterday I had my exam in linear algebra, the first of my two big
exams before summer, and it didn't go well at all. I don't want to be
a pessimist of course, but I'm very much afraid that I flunked it.
Guess I've been focusing too much on the multivar calculus, which is
the exam on Saturday, thinking I had the linear algebra pretty much in
the bag. Or I was just very unlucky with the questions. But in short;
I'll probably have to take the linear algebra exam again.

The reason I bring this up is that the next chance for me to take the
linear algebra exam again is on June 9 already, which is unusual;
usually it's not until the end of the summer. But I really need to
nail this one.

This means that up until June 9, in addition to GSoC, I'll have to
dedicate at least some of my daily brain power to doing maths. I'd say
a couple of hours or so.

But don't worry, I fully intend to start working full time on my GSoC
after the exam on Saturday, just like planned. I'll schedule these few
hours a day I need to spend on making sure I finally pass linear
algebra to early mornings, leaving a full work day + evenings for my
project.

Just thought I should keep you posted, so you know why you won't see
any commits from me in the early morning hours, as then I'll be
inverting matrices and other fun stuff, *shrug* :) Hope I didn't scare
you too much with the subject of this mail.

I contacted my professor and he promised that because of the unusually
short timespan up until the re-exam on June 9, they would have the
results in before the weekend. So by then I'll know for sure.

Regards,
Elvis


From cbradney at scribus.info  Wed May 25 22:11:04 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Thu, 26 May 2011 00:11:04 +0200
Subject: [scribus-dev] Possibly some (slightly!) bad news
In-Reply-To: <BANLkTikMoqNJLuy1tdFkHCws65sGibLYtA@mail.gmail.com>
References: <BANLkTikMoqNJLuy1tdFkHCws65sGibLYtA@mail.gmail.com>
Message-ID: <4DDD7E78.4010804@scribus.info>

On 5/25/11 11:48 PM, Elvis Stansvik wrote:
> Hi all,
> 
> Yesterday I had my exam in linear algebra, the first of my two big
> exams before summer, and it didn't go well at all. I don't want to be
> a pessimist of course, but I'm very much afraid that I flunked it.
> Guess I've been focusing too much on the multivar calculus, which is
> the exam on Saturday, thinking I had the linear algebra pretty much in
> the bag. Or I was just very unlucky with the questions. But in short;
> I'll probably have to take the linear algebra exam again.
> 
> The reason I bring this up is that the next chance for me to take the
> linear algebra exam again is on June 9 already, which is unusual;
> usually it's not until the end of the summer. But I really need to
> nail this one.
> 
> This means that up until June 9, in addition to GSoC, I'll have to
> dedicate at least some of my daily brain power to doing maths. I'd say
> a couple of hours or so.
> 
> But don't worry, I fully intend to start working full time on my GSoC
> after the exam on Saturday, just like planned. I'll schedule these few
> hours a day I need to spend on making sure I finally pass linear
> algebra to early mornings, leaving a full work day + evenings for my
> project.
> 
> Just thought I should keep you posted, so you know why you won't see
> any commits from me in the early morning hours, as then I'll be
> inverting matrices and other fun stuff, *shrug* :) Hope I didn't scare
> you too much with the subject of this mail.
> 
> I contacted my professor and he promised that because of the unusually
> short timespan up until the re-exam on June 9, they would have the
> results in before the weekend. So by then I'll know for sure.
> 
> Regards,
> Elvis
> 

Hi Elvis

Thanks for the news.. and bad luck for that exam.. that sucks.
Importantly, you are keeping us informed - we know what to expect.
Concentrate on your exams as much as you need!

Good luck!

thanks
Craig


From elvstone at gmail.com  Wed May 25 22:20:50 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Thu, 26 May 2011 00:20:50 +0200
Subject: [scribus-dev] Possibly some (slightly!) bad news
In-Reply-To: <4DDD7E78.4010804@scribus.info>
References: <BANLkTikMoqNJLuy1tdFkHCws65sGibLYtA@mail.gmail.com>
	<4DDD7E78.4010804@scribus.info>
Message-ID: <BANLkTinZ+0+rg8Geq=iYDZrV-adQb7kLAA@mail.gmail.com>

2011/5/26 Craig Bradney <cbradney at scribus.info>:
> On 5/25/11 11:48 PM, Elvis Stansvik wrote:
>> Hi all,
>>
>> Yesterday I had my exam in linear algebra, the first of my two big
>> exams before summer, and it didn't go well at all. I don't want to be
>> a pessimist of course, but I'm very much afraid that I flunked it.
>> Guess I've been focusing too much on the multivar calculus, which is
>> the exam on Saturday, thinking I had the linear algebra pretty much in
>> the bag. Or I was just very unlucky with the questions. But in short;
>> I'll probably have to take the linear algebra exam again.
>>
>> The reason I bring this up is that the next chance for me to take the
>> linear algebra exam again is on June 9 already, which is unusual;
>> usually it's not until the end of the summer. But I really need to
>> nail this one.
>>
>> This means that up until June 9, in addition to GSoC, I'll have to
>> dedicate at least some of my daily brain power to doing maths. I'd say
>> a couple of hours or so.
>>
>> But don't worry, I fully intend to start working full time on my GSoC
>> after the exam on Saturday, just like planned. I'll schedule these few
>> hours a day I need to spend on making sure I finally pass linear
>> algebra to early mornings, leaving a full work day + evenings for my
>> project.
>>
>> Just thought I should keep you posted, so you know why you won't see
>> any commits from me in the early morning hours, as then I'll be
>> inverting matrices and other fun stuff, *shrug* :) Hope I didn't scare
>> you too much with the subject of this mail.
>>
>> I contacted my professor and he promised that because of the unusually
>> short timespan up until the re-exam on June 9, they would have the
>> results in before the weekend. So by then I'll know for sure.
>>
>> Regards,
>> Elvis
>>
>
> Hi Elvis
>
> Thanks for the news.. and bad luck for that exam.. that sucks.
> Importantly, you are keeping us informed - we know what to expect.
> Concentrate on your exams as much as you need!
>
> Good luck!

Thanks! And let's hope it's not all down to luck next time ;)

Elvis


From plinnell at scribus.net  Fri May 27 01:29:26 2011
From: plinnell at scribus.net (Peter Linnell)
Date: Thu, 26 May 2011 18:29:26 -0700
Subject: [scribus-dev] 1.4.0 RC4
In-Reply-To: <4DDC1B86.1000708@scribus.info>
References: <4DDC1B86.1000708@scribus.info>
Message-ID: <4DDEFE76.6010401@scribus.net>

On 5/24/11 1:56 PM, Craig Bradney wrote:
> Hi All
>
> Jean and I agree that we should release an RC4. We have not fixed many
> bugs of late, however a few were fixed since RC3 and a few regular
> issues reported are exactly those that were fixed since RC3.
>
> mrdocs, do you have time to do the tag/release work this coming weekend?
> I'll be in Paris until Saturday night but can kick off builds on Sunday
> at a minimum for OSX (so don't wait for me).
>
> Thanks
> Craig

Hi,

I should be able to tag this over the weekend.

I am leaving SFO tomorrow my time mid day and stop over in Montreal late 
in the evening, then depart Montreal late Saturday. I arrive back in 
France mid-day Sunday.

I keep folks posted with my progress.



From cbradney at scribus.info  Mon May 30 10:54:08 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Mon, 30 May 2011 12:54:08 +0200
Subject: [scribus-dev] 1.4.0 RC4
In-Reply-To: <4DDEFE76.6010401@scribus.net>
References: <4DDC1B86.1000708@scribus.info> <4DDEFE76.6010401@scribus.net>
Message-ID: <4E198DCC-52CA-4FDA-B3AA-BB75007B973D@scribus.info>





On 27/05/2011, at 3:29, Peter Linnell <plinnell at scribus.net> wrote:

> On 5/24/11 1:56 PM, Craig Bradney wrote:
>> Hi All
>> 
>> Jean and I agree that we should release an RC4. We have not fixed many
>> bugs of late, however a few were fixed since RC3 and a few regular
>> issues reported are exactly those that were fixed since RC3.
>> 
>> mrdocs, do you have time to do the tag/release work this coming weekend?
>> I'll be in Paris until Saturday night but can kick off builds on Sunday
>> at a minimum for OSX (so don't wait for me).
>> 
>> Thanks
>> Craig
> 
> Hi,
> 
> I should be able to tag this over the weekend.
> 
> I am leaving SFO tomorrow my time mid day and stop over in Montreal late in the evening, then depart Montreal late Saturday. I arrive back in France mid-day Sunday.
> 
> I keep folks posted with my progress.
> 
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev

That was from last week. Any chance you can tag today? Just need to bump version and changelogs first. 

Thanks
Craig

From mrdocs at scribus.net  Mon May 30 10:54:33 2011
From: mrdocs at scribus.net (Peter Linnell)
Date: Mon, 30 May 2011 12:54:33 +0200
Subject: [scribus-dev] 1.4.0 RC4
In-Reply-To: <4E198DCC-52CA-4FDA-B3AA-BB75007B973D@scribus.info>
References: <4DDC1B86.1000708@scribus.info> <4DDEFE76.6010401@scribus.net>
	<4E198DCC-52CA-4FDA-B3AA-BB75007B973D@scribus.info>
Message-ID: <4DE37769.3020608@scribus.net>

On 05/30/2011 12:54 PM, Craig Bradney wrote:
> 
> 
> 
> 
> On 27/05/2011, at 3:29, Peter Linnell <plinnell at scribus.net> wrote:
> 
>> On 5/24/11 1:56 PM, Craig Bradney wrote:
>>> Hi All
>>>
>>> Jean and I agree that we should release an RC4. We have not fixed many
>>> bugs of late, however a few were fixed since RC3 and a few regular
>>> issues reported are exactly those that were fixed since RC3.
>>>
>>> mrdocs, do you have time to do the tag/release work this coming weekend?
>>> I'll be in Paris until Saturday night but can kick off builds on Sunday
>>> at a minimum for OSX (so don't wait for me).
>>>
>>> Thanks
>>> Craig
>>
>> Hi,
>>
>> I should be able to tag this over the weekend.
>>
>> I am leaving SFO tomorrow my time mid day and stop over in Montreal late in the evening, then depart Montreal late Saturday. I arrive back in France mid-day Sunday.
>>
>> I keep folks posted with my progress.
>>
>>
>> _______________________________________________
>> scribus-dev mailing list
>> scribus-dev at lists.scribus.net
>> http://lists.scribus.net/mailman/listinfo/scribus-dev
> 
> That was from last week. Any chance you can tag today? Just need to bump version and changelogs first. 
> 
> Thanks
> Craig


By tonight latest :)

TTYL,

Peter


