ale rimoldi
2018-09-10 17:01:27 UTC
buondì!
i've finally managed to solve an issue that has been buggin for a
very long time.
TLDR:
- i've added a new tab to "item > duplicate > multiple duplicate" to
duplicate an item on the following pages (all, even, odd, ranges;
with text links).
- this tab should replace the "insert > frames" dialog.
- this tab should replace the "automatic text frames" in the "file >
new" dialog.
You can try the feature by checking out (or applying the resulting
patch) my "insert-frames" branch:
https://github.com/aoloe/scribus/tree/insert-frames
https://github.com/scribusproject/scribus/compare/master...aoloe:insert-frames.diff
now, some details.
the genesis of this feature is related to the master page
items not being editable in the "real" pages.
one can use the guides and the scrapbook, and it's mostly fine. but it
would be nice to have some more automatism.
and -- as many of you already know -- i really don't like the automatic
text frames (at least not in the way they are provided by scribus).
i think that none of you has ever used the "insert > frames" dialog...
personally, i haven't, but i at sometimes i started planning to add a
button that takes the current selection as a template for the frame(s)
to be created.
i did create a local branch and started modifying the dialog.
but, wait... "item > duplicate > multiple duplicate" does almost the
same thing and it might be way easier!
i haven't renamed the branch, but i've restarted my work from scratch
and added a "By Page" tab to the "Multiple Duplicate" dialog.
https://imagebin.ca/v/4FENK8tSMgUM
looks simple?
the hardest part was: reducing it to the minimal interface that
makes it easy to use!
the features:
- you can duplicate the selected items on the following (odd / even)
pages
- you can duplicate them on a set of pages (as an example 1-4)
- if you check the "Link text frames" check box, the first text frame
found in the selection will be linked to the first text frame found
in the duplicated items (creating a chain through all the pages
concerned)
- if the text frame is already in a chain, the last frame in the
chain is used for linking to the first in the chain among the
duplicated items (harder to explain than to do...).
i won't spent many words, to explain why this should replace the
"insert > frames" dialog. but if somebody needs an explanation i can
take the time.
really, if this patch gets accepted, the "insert > frames" should be
removed.
and should it also replace the automatic text frames? in my eyes: yes!
here is a screencast showing how easily the auto text frame workflow
can be replaced by the multiple duplication:
https://my.mixtape.moe/kzzslw.webm
but why would like to remove the automatic frames from scribus, we can
keep both...?
- because automatic frames are not flexible. once you have set them in
the new > file dialog, you cannot change the option without
recreating the whole file.
it would require some serious work to make the automatic frames to be
flexible enough to be really useful (and avoid that people keep on
asking how they can do this and that with the automatic frames).
- because there is some cryptic code scattered over multiple places in
the code to allow the automatic frames: the new code for the multiple
duplicate by page is a friendly function with 70 lines of code.
- because learning about the multiple duplication gives you skills in a
tool you can use for several tasks.
the automatic text frames, are a feature that is hard to find (and
setup; well, it's not THAT hard... but it's not trivial either to
get right) and that you can use only for one single goal.
- because adding the needed flexibility to the auto text frames, will
probably require a UI (and a code) that is way more complex than
what we can achieve with the multiple duplication.
the scribus UI is already way too complex. the same is valid for the
code.
if there is a chance to simplify one or both of them, i really think we
should take it!
and now?
i'd love it, if other people could try out the feature and give
feedback.
in the near future, i'd like to upload the patch to the bug tracker (and
create a second patch to remove the two deprecated commands).
have a wonderful evening!
a.l.e
___
Scribus Mailing List: ***@lists.scribus.net
Edit your options or unsubscribe:
http://lists.scribus.net/mailman/listinfo/scribus
See also:
http://wiki.
i've finally managed to solve an issue that has been buggin for a
very long time.
TLDR:
- i've added a new tab to "item > duplicate > multiple duplicate" to
duplicate an item on the following pages (all, even, odd, ranges;
with text links).
- this tab should replace the "insert > frames" dialog.
- this tab should replace the "automatic text frames" in the "file >
new" dialog.
You can try the feature by checking out (or applying the resulting
patch) my "insert-frames" branch:
https://github.com/aoloe/scribus/tree/insert-frames
https://github.com/scribusproject/scribus/compare/master...aoloe:insert-frames.diff
now, some details.
the genesis of this feature is related to the master page
items not being editable in the "real" pages.
one can use the guides and the scrapbook, and it's mostly fine. but it
would be nice to have some more automatism.
and -- as many of you already know -- i really don't like the automatic
text frames (at least not in the way they are provided by scribus).
i think that none of you has ever used the "insert > frames" dialog...
personally, i haven't, but i at sometimes i started planning to add a
button that takes the current selection as a template for the frame(s)
to be created.
i did create a local branch and started modifying the dialog.
but, wait... "item > duplicate > multiple duplicate" does almost the
same thing and it might be way easier!
i haven't renamed the branch, but i've restarted my work from scratch
and added a "By Page" tab to the "Multiple Duplicate" dialog.
https://imagebin.ca/v/4FENK8tSMgUM
looks simple?
the hardest part was: reducing it to the minimal interface that
makes it easy to use!
the features:
- you can duplicate the selected items on the following (odd / even)
pages
- you can duplicate them on a set of pages (as an example 1-4)
- if you check the "Link text frames" check box, the first text frame
found in the selection will be linked to the first text frame found
in the duplicated items (creating a chain through all the pages
concerned)
- if the text frame is already in a chain, the last frame in the
chain is used for linking to the first in the chain among the
duplicated items (harder to explain than to do...).
i won't spent many words, to explain why this should replace the
"insert > frames" dialog. but if somebody needs an explanation i can
take the time.
really, if this patch gets accepted, the "insert > frames" should be
removed.
and should it also replace the automatic text frames? in my eyes: yes!
here is a screencast showing how easily the auto text frame workflow
can be replaced by the multiple duplication:
https://my.mixtape.moe/kzzslw.webm
but why would like to remove the automatic frames from scribus, we can
keep both...?
- because automatic frames are not flexible. once you have set them in
the new > file dialog, you cannot change the option without
recreating the whole file.
it would require some serious work to make the automatic frames to be
flexible enough to be really useful (and avoid that people keep on
asking how they can do this and that with the automatic frames).
- because there is some cryptic code scattered over multiple places in
the code to allow the automatic frames: the new code for the multiple
duplicate by page is a friendly function with 70 lines of code.
- because learning about the multiple duplication gives you skills in a
tool you can use for several tasks.
the automatic text frames, are a feature that is hard to find (and
setup; well, it's not THAT hard... but it's not trivial either to
get right) and that you can use only for one single goal.
- because adding the needed flexibility to the auto text frames, will
probably require a UI (and a code) that is way more complex than
what we can achieve with the multiple duplication.
the scribus UI is already way too complex. the same is valid for the
code.
if there is a chance to simplify one or both of them, i really think we
should take it!
and now?
i'd love it, if other people could try out the feature and give
feedback.
in the near future, i'd like to upload the patch to the bug tracker (and
create a second patch to remove the two deprecated commands).
have a wonderful evening!
a.l.e
___
Scribus Mailing List: ***@lists.scribus.net
Edit your options or unsubscribe:
http://lists.scribus.net/mailman/listinfo/scribus
See also:
http://wiki.