[List] Welcome

[ale rimoldi]

hi anil,

>    I would like to introduce following ideas as well for this project
> 
>    1. Arrange the property pallet for the objects in a more user
> friendly manner.
>    2. Resolve the issues of direct editing of indic languages in text
> objects.
>    3. Implement Arabic rendering
>    4. Implement an editorial work flow plugin

while all of those four issues are very important, in this specific
project -- at least for now -- i prefer avoiding bothering with the
GUI.

i've been discussing my ideas with many people during the last several
months and most people at first where puzzled by my decision to
propose a command line scribus.
(most of all because one of my biggest concerns in scribus is the GUI!)

two main reasons made me go for it:

- we need new programmers joining but

  - the scribus core code is in a shape that scares away most of the
    brave programmers who dare to read it (seriously, files with
    more than a dozen thousands lines!)

  - the flow of the code is not documented and nobody really
    understands what is happening.
    (i'm looking at the file loaders right now: i have the feeling
    that scribus checks three times if the file exists and at least as
    often which kind of file it is... i've spent the last two hours,
    trying to document all the calls until scribus starts reading the
    first bit from a file).

  - the code is jealously stored on a server somewhere in finland and
    not on github (or a similar place), where all the programmers hang
    around and happily fork each others code before making pull
    requests.

  - in the past there were some programmers interested in getting
    scribus to work as a terminal app (iirc i have four different
    packages sitting on my HD that are supposed to process .SLAs
    into .PDFs! never managed to get any of them to work). let's see if
    some of them still want to work on it!

- i want to get as fast as possible something that works and people
  want to use. a console application is in my mind what is the fastest
  to achieve.

- i want to produce a base for further experiments around scribus, and
  here i am -- at least -- matching your point 4.: working on new
  editorial work flows!



concerning the points 2 and 3, personally, i have no skills with the
rendering of text and fonts (and generally speaking with rendering):
as soon as i have some working code, we can check if it is easier to get
arabic and indic scripts to work correctly in the main scribus or in a
new GUI module that is using the engine i'm creating.


btw, watching...

Introducing Qt Quick Controls in Qt 5.1 
http://www.youtube.com/watch?v=_6_F6Kpjd-Q

... made me think that Qt is making it easier and easier to create a
set of GUIs around a core...


back to the present.

right now, i'm starting with something, i have already done in other
contexts (reading XML files and producing PDFs) and i'm trying to
produce some code that may be useful in the main scribus... and if it
does not make it into scribus, it can still match the needs of many
people!

hopefully, i'll get to it!


and, all help is welcome!

the first step is done: there is a console program that starts,
reads the arguments and stops without crashing.
a simple plugin loader is also already implemented (cf. the read_sla
branch on github) and right now, i'm working on the first plugin
that will be reading a 1.5 SLA!
6563 LOC of scribus150format.cpp are waiting for me!


but there are things that other people can already do. as an example:

- defining and setting up a testing strategy and framework
- finding a way to document the flow of the code.
- setting up doxygen for the code documentation
- improving the plugin loader (if needed by moving to qt 5)
- finding out how to get the plugins to be compiled when running "make"
  in the core program.

there are tickets for each of those tasks in
https://github.com/impagina/core/issues/


the weekend is coming closer, it will be rainy and all of you will have
lot of time :-)

i wish you a wonderful evening
a.l.e