www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - COMPO

reply "Steve Teale" <steve.teale britseyeview.com> writes:
A deb file of an early version of COMPO2 is now available at 
http://britseyeview.com/compo/.

I'd appreciate some feedback from the Debian based users in the D 
community. It's not technical stuff, but it's an example of what 
can be done with D+gtkd2.

Also, with a little tutoring, your kids might like it.

I have to take a break from developing it, and write some 
documentation now.
Feb 07 2014
next sibling parent "Uplink_Coder" <someemail someprovider.some> writes:
On Saturday, 8 February 2014 at 06:03:18 UTC, Steve Teale wrote:

 A deb file of an early version of COMPO2 is now available at 
 http://britseyeview.com/compo/.

 I'd appreciate some feedback from the Debian based users in the 
 D community. It's not technical stuff, but it's an example of 
 what can be done with D+gtkd2.

 Also, with a little tutoring, your kids might like it.

 I have to take a break from developing it, and write some 
 documentation now.


I think it's a nice piece of work
Feb 08 2014
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Sat, 2014-02-08 at 06:03 +0000, Steve Teale wrote:

 A deb file of an early version of COMPO2 is now available at 
 http://britseyeview.com/compo/.
 
 I'd appreciate some feedback from the Debian based users in the D 
 community. It's not technical stuff, but it's an example of what 
 can be done with D+gtkd2.


I downloaded the deb file and put into my local deb repository. On
update, the package appears to aptitude, but as an i386, 32-bit package.
Although I am running a multiarch 64-bit Debian Unstable, compo was
going to drag in 62 new i386 packages, which I'm afraid felt a bit to
much to continue with.

Can I suggest:

1.  use the Debian package naming rules so that the version number and
architecture are more standardly part of the name.

2. build a 64-bit amd64 package as well as a 32-bit i386 package.

Thanks.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Feb 08 2014
parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Saturday, 8 February 2014 at 17:32:05 UTC, Russel Winder wrote:

 1.  use the Debian package naming rules so that the version 
 number and
 architecture are more standardly part of the name.

 2. build a 64-bit amd64 package as well as a 32-bit i386 
 package.


I have changed the naming to make it clear that it is a 32 bit 
version. However it's not clear to me whether I can build a 64 
bit version on my 32 bit system.

a) How do I tell if my GCC version is multilib,
b) Can I build a static 64 bit library - gtkd2 - on my 32 bit 
system.

Thanks Steve
Feb 08 2014
next sibling parent Russel Winder <russel winder.org.uk> writes:
On Sun, 2014-02-09 at 07:25 +0000, Steve Teale wrote:
[…]

 I have changed the naming to make it clear that it is a 32 bit 
 version. However it's not clear to me whether I can build a 64 
 bit version on my 32 bit system.


Should be possible if you have the 64-bit libraries, it's just a form of
cross-compilation.


 a) How do I tell if my GCC version is multilib,


GCC just has flags to determine whether it does 32-bit or 64-bit
compilation and linking. The only issue is whether you have the 32-bit
libraries to link against.

For Debian (and Ubuntu, and some variants of Mint) ensure you have the
multiarch-support and binutils-multiarch in place. Probably best to see
https://wiki.debian.org/Multiarch


 b) Can I build a static 64 bit library - gtkd2 - on my 32 bit 
 system.


Should be able to, DMD, GDC and LDC can all cross-compile.

If you send me a reference to your deb build repository, I'll clone it
and give a build a try here, save you the hassle.

PS I thought the idea of D application compilation was not to build
separate objects for each source and then link (as in your Makefile),
but to compile and link all sources in one step (makes the Makefile
simpler :-) 

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Feb 09 2014
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
Steve,

I cloned your Git repository. Instead of editing your Makefile to switch
from your file structure to mine, I created a SCons build, using the
separate compilation approach for now. with my 64-bit build of your
code, I am seeing errors such as:

acomp.d(782): Error: cannot implicitly convert expression
(parent.children.length + 1LU) of type ulong to int
acomp.d(801): Error: cannot implicitly convert expression (p.children.length +
1LU) of type ulong to int
acomp.d(857): Error: cannot implicitly convert expression (p.children.length)
of type ulong to int

so it looks like your code is 32-bit specific. I guess this is the
ago-old problem of C, C++, D, etc. that int is the most natural size for
the platform, code is inherently not as portable as you think.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Feb 09 2014
parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Sunday, 9 February 2014 at 09:36:15 UTC, Russel Winder wrote:

 Steve,

 I cloned your Git repository. Instead of editing your Makefile 
 to switch
 from your file structure to mine, I created a SCons build, 
 using the
 separate compilation approach for now. with my 64-bit build of 
 your
 code, I am seeing errors such as:

 acomp.d(782): Error: cannot implicitly convert expression 
 (parent.children.length + 1LU) of type ulong to int
 acomp.d(801): Error: cannot implicitly convert expression 
 (p.children.length + 1LU) of type ulong to int
 acomp.d(857): Error: cannot implicitly convert expression 
 (p.children.length) of type ulong to int

 so it looks like your code is 32-bit specific. I guess this is 
 the
 ago-old problem of C, C++, D, etc. that int is the most natural 
 size for
 the platform, code is inherently not as portable as you think.


Thanks Russel. I suspected that would be the case - like you say, 
old habits die hard. I guess I'll have to install 64 bit Ubuntu 
on my laptop so I have somewhere to launder the code, and build 
64 bit.

Steve
Feb 09 2014
prev sibling parent Russel Winder <russel winder.org.uk> writes:
Steve,

I switched my SCons build to "all at once":

dmd -I/home/users/russel/lib.Linux.x86_64/GtkD_DMD/include/d/gtkd-2 -ofcompo
about.d acomp.d arrow.d avery.d bevel.d brushdabs.d circle.d common.d compo.d
config.d constants.d container.d controlsdlg.d controlset.d corner.d crescent.d
cross.d csv.d curve.d deserialize.d drawing.d fader.d fancytext.d generic.d
graphics.d heart.d interfaces.d keyvals.d lgradient.d line.d lineset.d
mainwin.d menus.d merger.d mesh.d moon.d morphdlgs.d morphs.d morphtext.d
noise.d partition.d pattern.d pglayout.d pixelimage.d pointset.d polycurve.d
polygon.d printing.d random.d rect.d reference.d regpc.d regpoly.d rgradient.d
richtext.d rsvgwrap.d separator.d serial.d serialize.d settings.d shapelib.d
sheets.d strokeset.d svgimage.d tb2pm.d text.d textsrc.d tilings.d tree.d
treeops.d triangle.d tvitem.d types.d uspsib.d
acomp.d(782): Error: cannot implicitly convert expression
(parent.children.length + 1LU) of type ulong to int
acomp.d(801): Error: cannot implicitly convert expression (p.children.length +
1LU) of type ulong to int
acomp.d(857): Error: cannot implicitly convert expression (p.children.length)
of type ulong to int
avery.d(221): Error: cannot implicitly convert expression (this.sheets.length)
of type ulong to int
avery.d(672): Error: cannot implicitly convert expression (this.sheets.length)
of type ulong to int
controlset.d(224): Error: cannot implicitly convert expression (this.wia.length
- 1LU) of type ulong to int
csv.d(129): Error: cannot implicitly convert expression (atemp.length) of type
ulong to int
deserialize.d(257): Error: cannot implicitly convert expression
(lastIndexOf(cast(const(char)[])this.fileName, "/", cast(CaseSensitive)1)) of
type long to int
generic.d(48): Error: cannot implicitly convert expression (this.sheets.length)
of type ulong to int
generic.d(91): Error: cannot implicitly convert expression (this.sheets.length)
of type ulong to int
merger.d(728): Error: cannot implicitly convert expression
(indexOf(cast(const(char)[])this.md.spec, cast(const(char)[])colSpec,
cast(CaseSensitive)1)) of type long to int
merger.d(735): Error: cannot implicitly convert expression (cast(ulong)pos +
colSpec.length) of type ulong to int
pglayout.d(316): Error: cannot implicitly convert expression
(this.marked.length) of type ulong to int
pixelimage.d(309): Error: cannot implicitly convert expression
(lastIndexOf(cast(const(char)[])this.fileName, '/', cast(CaseSensitive)1)) of
type long to int
pointset.d(136): Error: cannot implicitly convert expression
(this.po.oPath.length) of type ulong to int
pointset.d(235): Error: cannot implicitly convert expression
(this.po.editStack.length) of type ulong to int
polycurve.d(75): Error: cannot implicitly convert expression
(this.po.pcPath.length) of type ulong to int
polycurve.d(184): Error: cannot implicitly convert expression
(this.po.pcPath.length) of type ulong to int
polycurve.d(328): Error: cannot implicitly convert expression
(this.po.editStack.length) of type ulong to int
polycurve.d(685): Error: cannot implicitly convert expression
(this.pcPath.length - 1LU) of type ulong to int
polycurve.d(1040): Error: cannot implicitly convert expression
(this.pcPath.length) of type ulong to int
scons: *** [compo] Error 1
scons: building terminated because of errors.

I guess we should take this off this list and over to the GitHub issues?

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Feb 09 2014
prev sibling next sibling parent reply "angel" <andrey.gelman gmail.com> writes:
Trying to build from source, I run into missing 'mainwin.d' file.
 From the git history it seems like some time ago main.d was 
renamed to mainwin.d, but no mainwin.d seems to be present in the 
repository.
Feb 08 2014
parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Sunday, 9 February 2014 at 00:17:01 UTC, angel wrote:

 Trying to build from source, I run into missing 'mainwin.d' 
 file.
 From the git history it seems like some time ago main.d was 
 renamed to mainwin.d, but no mainwin.d seems to be present in 
 the repository.


I'll fix it.
Feb 08 2014
parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Sunday, 9 February 2014 at 05:48:06 UTC, Steve Teale wrote:

 On Sunday, 9 February 2014 at 00:17:01 UTC, angel wrote:

 Trying to build from source, I run into missing 'mainwin.d' 
 file.
 From the git history it seems like some time ago main.d was 
 renamed to mainwin.d, but no mainwin.d seems to be present in 
 the repository.


 I'll fix it.


Fixed now I hope. I had to change the name of main.d so I could 
write the stub compo.d file required by DUB. If I imported main 
into that, it clashed with main().

A bunch of changes were added at the same time, so what's there 
now should be the same as what created the current deb file.
Feb 08 2014
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 8 February 2014 06:03, Steve Teale <steve.teale britseyeview.com> wrote:

 A deb file of an early version of COMPO2 is now available at
 http://britseyeview.com/compo/.

 I'd appreciate some feedback from the Debian based users in the D community.
 It's not technical stuff, but it's an example of what can be done with
 D+gtkd2.

 Also, with a little tutoring, your kids might like it.

 I have to take a break from developing it, and write some documentation now.


Looks like some old British twit has been taking the mushrooms again.
This is all quite beyond me! ;-)

Having a quick look at the source on github.  I would suggest to not
have a flat module hierarchy (ie: move them all into 'compo').

Regards
Iain
Feb 09 2014
parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Sunday, 9 February 2014 at 22:48:23 UTC, Iain Buclaw wrote:

 Looks like some old British twit has been taking the mushrooms 
 again.
 This is all quite beyond me! ;-)

 Having a quick look at the source on github.  I would suggest 
 to not
 have a flat module hierarchy (ie: move them all into 'compo').

 Regards
 Iain


You mean one humungous file?
Feb 09 2014
next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
I believe Iain is suggesting you put your source code into a folder called
compo/. In Dub you would generally put the sources in Source/ then have
project files in the root of the project folder Readme and License for
example.


On Mon, Feb 10, 2014 at 7:02 AM, Steve Teale
<steve.teale britseyeview.com>wrote:


 On Sunday, 9 February 2014 at 22:48:23 UTC, Iain Buclaw wrote:


 Looks like some old British twit has been taking the mushrooms again.
 This is all quite beyond me! ;-)

 Having a quick look at the source on github.  I would suggest to not
 have a flat module hierarchy (ie: move them all into 'compo').

 Regards
 Iain


 You mean one humungous file?
Feb 09 2014
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 10 Feb 2014 05:06, "Steve Teale" <steve.teale britseyeview.com> wrote:

 On Sunday, 9 February 2014 at 22:48:23 UTC, Iain Buclaw wrote:

 Looks like some old British twit has been taking the mushrooms again.
 This is all quite beyond me! ;-)

 Having a quick look at the source on github.  I would suggest to not
 have a flat module hierarchy (ie: move them all into 'compo').

 Regards
 Iain



 You mean one humungous file?


Nope. Create a directory 'compo', move all sources I. The folder and update
the module names from 'module text' -> 'module compo.text'
Feb 09 2014
parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Monday, 10 February 2014 at 07:11:17 UTC, Iain Buclaw wrote:


 You mean one humungous file?


 Nope. Create a directory 'compo', move all sources I. The 
 folder and update
 the module names from 'module text' -> 'module compo.text'


Iain,

I live in fear of fracturing CodeBlocks fragile project 
structure. But it's a good suggestion. I am frantically trying to 
get COMPO to a state of some usability, and built for Windows, 
with documentation, before I die.

When I am calmer I will take up your point. It would probably 
help me in getting collaborators, and would suit DUB.
Feb 10 2014
prev sibling parent Rory McGuire <rjmcguire gmail.com> writes:
:) ah right, you did say module.



On Mon, Feb 10, 2014 at 9:11 AM, Iain Buclaw <ibuclaw gdcproject.org> wrote:


 On 10 Feb 2014 05:06, "Steve Teale" <steve.teale britseyeview.com> wrote:

 On Sunday, 9 February 2014 at 22:48:23 UTC, Iain Buclaw wrote:

 Looks like some old British twit has been taking the mushrooms again.
 This is all quite beyond me! ;-)

 Having a quick look at the source on github.  I would suggest to not
 have a flat module hierarchy (ie: move them all into 'compo').

 Regards
 Iain



 You mean one humungous file?


 Nope. Create a directory 'compo', move all sources I. The folder and
 update the module names from 'module text' -> 'module compo.text'
Feb 10 2014
prev sibling parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Saturday, 8 February 2014 at 06:03:18 UTC, Steve Teale wrote:


 I have to take a break from developing it, and write some 
 documentation now.


OK, I have made some reasonably complete documentation, and that 
now replaces the COMPO stuff I had on the web at 
http://britseyeview.com/compo/.

The binary that is available there is still just i386. My next 
job is to install Ubuntu 12.04 64 bit as dual boot on my machine, 
and attempt to build an amd64 version.

The binary matches what is currently on GitHub.

I would love to get some feedback on both the application and the 
documentation



 Feb 16 2014



  parent reply "Steve Teale" <steve.teale britseyeview.com>  writes:


On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote:

 I would love to get some feedback on both the application and 
 the documentation


Have now done a dual-boot install of Ubuntu 12.04 64 bit, and 
built COMPO using that. Seems to pass limited sanity testing. 
Will make a .deb file tomorrow.



 Feb 17 2014



  parent reply "Steve Teale" <steve.teale britseyeview.com>  writes:


On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote:

 On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote:

 I would love to get some feedback on both the application and 
 the documentation




You must forgive me for harping on about this, but I am going to 
be persistent. Between COMPO 1 and COMPO 2, there's the best 
part, or more, of a man-year's work. So I won't let go lightly.

Today I have posted two new .deb files (i386/amd64) on the COMPO 
web site - http://britseyeview.com/compo/. There's decent online 
documentation at the same place. The stage of operations is now 
QA, and since I am the author, you know that at this point, I 
need help ;=)

The source code is also up-to-date on 
https://github.com/britseye/compo.

Come on guys, give me an hour of your precious time.

Steve



 Feb 24 2014



 next sibling parent reply Rory McGuire <rjmcguire gmail.com>  writes:


Hi Steve,

I would like to look just crazy busy at the moment.
Are you just wanting feed back on the code or testing the app and criting
the code?
On 24 Feb 2014 18:35, "Steve Teale" <steve.teale britseyeview.com> wrote:


 On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote:


 On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote:


 I would love to get some feedback on both the application and the
 documentation




 You must forgive me for harping on about this, but I am going to be
 persistent. Between COMPO 1 and COMPO 2, there's the best part, or more, of
 a man-year's work. So I won't let go lightly.

 Today I have posted two new .deb files (i386/amd64) on the COMPO web site
 - http://britseyeview.com/compo/. There's decent online documentation at
 the same place. The stage of operations is now QA, and since I am the
 author, you know that at this point, I need help ;=)

 The source code is also up-to-date on https://github.com/britseye/compo.

 Come on guys, give me an hour of your precious time.

 Steve





 Feb 24 2014



  parent  "Steve Teale" <steve.teale britseyeview.com>  writes:


On Monday, 24 February 2014 at 18:08:34 UTC, Rory McGuire wrote:

 Hi Steve,

 I would like to look just crazy busy at the moment.
 Are you just wanting feed back on the code or testing the app 
 and criting
 the code?


What I need most is comment on the usability and scope of the 
application - am I wasting my time if I continue to work on it?

If you think it's OK, then testing. It's always difficult to 
critically test your own application. You know how it works and 
what it's supposed to do, and that knowledge channels you.

I mostly know where the code is a mess, and can fix that over 
time. At the moment I'm sticking to the old adage - if it ain't 
broken, don't mend it.

Thanks
Steve



 Feb 24 2014



prev sibling  parent reply "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Monday, 24 February 2014 at 16:30:43 UTC, Steve Teale wrote:

 On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote:

 On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote:

 I would love to get some feedback on both the application and 
 the documentation




 You must forgive me for harping on about this, but I am going 
 to be persistent. Between COMPO 1 and COMPO 2, there's the best 
 part, or more, of a man-year's work. So I won't let go lightly.

 Today I have posted two new .deb files (i386/amd64) on the 
 COMPO web site - http://britseyeview.com/compo/. There's decent 
 online documentation at the same place. The stage of operations 
 is now QA, and since I am the author, you know that at this 
 point, I need help ;=)

 The source code is also up-to-date on 
 https://github.com/britseye/compo.

 Come on guys, give me an hour of your precious time.

 Steve


However I go about building this, I get linker errors about 
libusps4cb.a

Where can I find the source for this library? Or at the very 
least can you upload a x86_64 version?



 Feb 25 2014



  parent reply "Steve Teale" <steve.teale britseyeview.com>  writes:


On Wednesday, 26 February 2014 at 00:43:58 UTC, John Colvin wrote:

 On Monday, 24 February 2014 at 16:30:43 UTC, Steve Teale wrote:

 On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote:

 On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale 
 wrote:

 I would love to get some feedback on both the application 
 and the documentation




 You must forgive me for harping on about this, but I am going 
 to be persistent. Between COMPO 1 and COMPO 2, there's the 
 best part, or more, of a man-year's work. So I won't let go 
 lightly.

 Today I have posted two new .deb files (i386/amd64) on the 
 COMPO web site - http://britseyeview.com/compo/. There's 
 decent online documentation at the same place. The stage of 
 operations is now QA, and since I am the author, you know that 
 at this point, I need help ;=)

 The source code is also up-to-date on 
 https://github.com/britseye/compo.

 Come on guys, give me an hour of your precious time.

 Steve




John,

I'm sorry. Trying to do too many things at the same time. 
libusps4cb is a binary provided by the US Postal Service for 
creating postal bar codes. They don't publish the source.

I had the .a file for COMPO1, and that still seems to work OK, 
but they don't do static libraries any more, so for a 64 bit 
build you'll need to use libusps4cb.so.  They are both in 
compo/lib on GitHub. The .a file is 32 bit, and the .so file 64 
bit.

Steve

I will get the 32 bit .so file and regularize the situation

 However I go about building this, I get linker errors about 
 libusps4cb.a

 Where can I find the source for this library? Or at the very 
 least can you upload a x86_64 version?





 Feb 26 2014



  parent reply Rory McGuire <rjmcguire gmail.com>  writes:


Steve,

Does compo2 allow you to add effects to layers?


On Wed, Feb 26, 2014 at 10:26 AM, Steve Teale
<steve.teale britseyeview.com>wrote:


 On Wednesday, 26 February 2014 at 00:43:58 UTC, John Colvin wrote:


 On Monday, 24 February 2014 at 16:30:43 UTC, Steve Teale wrote:


 On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote:


 On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote:


 I would love to get some feedback on both the application and the
 documentation




 You must forgive me for harping on about this, but I am going to be
 persistent. Between COMPO 1 and COMPO 2, there's the best part, or more, of
 a man-year's work. So I won't let go lightly.

 Today I have posted two new .deb files (i386/amd64) on the COMPO web
 site - http://britseyeview.com/compo/. There's decent online
 documentation at the same place. The stage of operations is now QA, and
 since I am the author, you know that at this point, I need help ;=)

 The source code is also up-to-date on https://github.com/britseye/compo.

 Come on guys, give me an hour of your precious time.

 Steve


  John,


 I'm sorry. Trying to do too many things at the same time. libusps4cb is a
 binary provided by the US Postal Service for creating postal bar codes.
 They don't publish the source.

 I had the .a file for COMPO1, and that still seems to work OK, but they
 don't do static libraries any more, so for a 64 bit build you'll need to
 use libusps4cb.so.  They are both in compo/lib on GitHub. The .a file is 32
 bit, and the .so file 64 bit.

 Steve

 I will get the 32 bit .so file and regularize the situation

  However I go about building this, I get linker errors about libusps4cb.a

 Where can I find the source for this library? Or at the very least can
 you upload a x86_64 version?







 Feb 26 2014



  parent reply "Steve Teale" <steve.teale britseyeview.com>  writes:


On Wednesday, 26 February 2014 at 08:41:29 UTC, Rory McGuire 
wrote:

 Steve,

 Does compo2 allow you to add effects to layers?


A composition is:

Container
    - Layer 1
    - Layer 2
    - Layer 3
    ...

The layers can be of any kind, including effects, though if they 
are not in a sensible order, opaque layers will hide layers 
underneath.

A file can be:

Composition 1
Composition 2
Layer 4
Layer 5
...

In any order.

Layers in a composition may use other compositions or stand-alone 
layers (e.g. Layer 4) as fill, so in that sense, yes, you can add 
effects to a layer as long as the layer is a closed and fillable 
figure. All but one of the closed figure types are fillable.

Steve



 Feb 26 2014



  parent  "Steve Teale" <steve.teale britseyeview.com>  writes:


I've just had a hack at the structure of the GitHub repo.
It is now, as suggested by Iain Bucklaw, less flat. The source is 
in a separate directory, and I've added a package.json file at 
the top level so COMPO can be built with DUB.

I also updated the README file to talk about library 
dependencies, put both makefiles (32 and 64) in a makefiles 
directory, and added libusps4cb.so (see the README).

I hope it is gradually getting more civilized.

Steve



 Feb 26 2014