[scribus-dev] Scribus CTL
Dawood al-badi
dawood.albadi at gmail.com
Thu Jan 21 09:40:27 UTC 2016
Hi Andreas
Nice to hear from you. About m_gb I did not delete it because I used it
previously in other classes like ps and I didnt modified these classes yet
because I was buzzy fixing textFrame so I leave it to avoid compilation
errors.
I will update you with my status in github today.
Regards
2016-01-21 13:14 GMT+04:00 Andreas Vox <avox at arcor.de>:
> Hello Dawood,
>
>
>
> sorry for dropping off the radar. I promise I’ll look at your code this
> weekend.
>
> From what I’ve seen it looks good. The last version I checked still hat
> the m_gb member in PageItem_TextFrame. Is that still in or have you
> eliminated it by now?
>
>
>
> I’ll also sync ScribusCTL master with SVN so that you get the recent
> changes from trunk.
>
>
>
> Best regards,
>
> Andreas
>
>
>
> *From:* Dawood al-badi [mailto:dawood.albadi at gmail.com]
> *Sent:* Mittwoch, 20. Januar 2016 10:35
> *To:* Scribus Development Mailing List
> *Subject:* Re: [scribus-dev] Scribus CTL
>
>
>
> Hi ale
>
> I will consider that option later when I go deeper in CTL if Andreas still
> not responding because it seems no one from core developers have any
> interest on CTL other than Andreas. If I make my changes on my own I afraid
> that no one will accept that huge changes so I will wait until no other
> option.
>
> thanks
>
>
>
> 2016-01-20 12:18 GMT+04:00 ale rimoldi <ale.comp_06 at xox.ch>:
>
> hey dawood
>
> i've not seen any reply by andreas, so you might want to go for an
> alternative -- and less straightforward -- workflow...
>
> in my previous mail, i've drafted a few hints, how the integration of your
> work could happen.
>
> depending on your own ideas and/or other constraints you might want to
> build upon it and find a good way to get your work into the trunk!
>
> if you need help, just raise your hand :-)
>
> ciao
> a.l.e
>
>
>
>
> On 12/01/16 12:09, ale rimoldi wrote:
>
> hi dawood!
>
> nice to read about your progress!
>
> i think that for the global architecture andreas will have to give you the
> ok...
>
> on the other side, the longer you wait with sending your patches, the
> harder it is to
>
> - integrate them into the scribus trunk
> - make sure that they don't break anything
>
> i'm not skilled with CTL and i only know a bit of scribus code, but i
> skimmed through the diff between your branch and andreas' one and what i
> saw looks good...
>
> since andreas did not fork the scribusproject repository, i cannot use
> github to check for the differences between his branch and the trunk... so
> i cannot tell how different your code from the current trunk...
>
> my suggestion is:
>
> - become confident that your changes do not break non-CTL rendering on
> screen and in the PDFs (you can ask the community to compile your version
> and try it with their documents)
>
> - create a new (github) repository that is based on scribus trunk (as an
> example by forking scribusproject's github repository).
>
> - as far as possible, add branches that contain atomic changes to the
> scribus code. describe each time why you are making the changes and what is
> the final goal. and create patches that change one thing at a time
>
> - you can also create one branch with your current code (but based on
> trunk instead of avox's repository), so that it's easy to get a full view
> of the differences between your current state and the trunk. that way
> you/we also can check if your code can still be applied to the current
> trunk!
>
> - start by sending patches that only contain new formatting for the code
> (thinks like indents...)
>
> - continue with patches that do not change the logic of the code (like
> adding new structures; of course you will have to explain why you(or avox)
> are adding them and link to the places where you will be using them so that
> the team can give you feedback).
>
> - then, if it's possible, create patches that add one feature at a time.
> document what you have done and why.
>
> - since avox is "in charge" of the whole ctl project, you might want to
> continue to work in your current repository based on his work, and only use
> the new repository for creating the patches and showing your work to the
> rest of the team / the rest of the community.
>
> the alternative is to add one big patch to the bug tracker and see what
> happens :-)
> it might be good enough!
>
> thanks for your precious work and have a wonderful evening
> a.l.e
>
> On 12/01/16 11:07, Dawood al-badi wrote:
>
> Hello developers.
>
> I am working in ScribusCTL with guidance of Andreas-VOX. I started to
> complete Andreas work and I almost finished first stage which is box
> implementation. This stage have a huge changes in Scribus code. I Think
> that when we finish and stabilize box implementation will be very difficult
> to merge that huge of change. Also I believe that Andreas last merge was
> with r20300 so we already in not updated version. Good to know that my work
> was to make Andreas modifications work correctly without logic and syntax
> error and my current state is as following. Scribus now use boxes to draw
> glyphs on screen correctly and it can export that text to pdf format.
> Although there still some bugs that I am working on it right now such as
> TAB and point to position. I am just wondering how can I proceed with that
> unupdated version because when I finish I believe that scribus will be much
> different from the version that I am working on now. I notice that Andreas
> is very buzy and he did not test my work. Now I need you to tell me if I
> should start to send patches of my changes or I wait for Andreas to test it
> and merge but in case I hope you can start test our code and report bugs
>
>
>
> https://github.com/dawoodalbadi/ScribusCTL
>
>
>
> regards
>
> Dawood
>
>
>
> _______________________________________________
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20160121/fcf3b14e/attachment.html>
More information about the scribus-dev
mailing list