Just seen a new computer interface technology directly from "spaceship
Please watch the movie and throw your mouse out of the window.
Okay, so it turned out that I was still subscribed under an old email address,
but my mailers sends everyone with the current one. Anyway, my fault, and I
would like to thank Manish for helping me out of my bewilderment. What I
wanted to propose & work on after my 1.5 release is the following:
Cooperating on get an OpenDocument specification for layered raster images
done and into the OASIS OpenDocument standard. Krita would use that format
for its native format, of course, as all of KOffice is moving to
OpenDocument automatically means some choices are made for us: a zip file
store, a certain layout inside that store, and xml main document and
resources for the binary data. Those choices may not be the best possible
technical choices, but Krita already uses a similar mechanism and it seems to
And since the Gimp and Krita have a different set of capabilities, we'd have
to make a flexible and complete specification, one that includes all possible
(possibly uninvented as yet) color models, adjustment layers, paths (which
Krita doesn't have) and so on.
I would really like to cooperate on this, since a standard used by one
application isn't a standard at all and since it would mean much better
interchange of documents than would be possible through either Photoshop
(ancient version 6 or reverse-engineered later versions) or XCF.
I'm prepared to do most of the writing & nagging of David Faure about
procedures and guidelines, but I'm not knowledgeable enough to do it all on
recent changes (I believe those made to the swatches panel) induced a
change in appearance of the status bar. OSX windows decorations hide
the zoom buttons. it was corrected before but the buttons are hidden
again in today's svn.
thank you in advance for us poor OS X users who do not have control
over the window decorations style :-)
in addition I had the impression that the panels were under the
status bar and not above in some fairly recent svn builds. personally
I preferred that but I can just be inventing this...
(the drag and drop from the panels is great BTW)
Windows, c'est un peu comme le beaujolais nouveau :
a chaque nouvelle cuvee on sait que ce sera degueulasse,
mais on en prend quand meme par masochisme.
On Friday 03 March 2006 22:31, Jaroslaw Staniek wrote:
> I wonder why OASIS picked to only use compressed XML as a medium:
> -it will also not work well for video data, BTW.
> -OpenOffice.org Base already failed to deliver robust solution because
> 100% of the data has to be processed on loading/saving (unless it's
> stored on the server).
This has nothing to do with the chosen file format and everything to
do with the implementation.
Zip is block based and you can do partial (un)compression.
XML need not be parsed 100% for it to be usable.
There are applications that can read some items from a huge XML
without parsing all, or even most of it. I know this for a fact, I
wrote a few.
In short; these worries should not effect the standardization efforts.
I tried to build Inkscape on Mac OS X 10.4, did everything as
described on wiki, it seems as everything succeed, but I get an error
"You cannot open the application Inkscape.app because it may be
damaged or incomplete" while running .app file.
Maybe anyone has run into similar problems and knows a quick solution?
Message from Inkscape submission form
Please note, that the submitter may not read this list.
CC your answer to the submitter
name: Leland McInnes
submitted the following:
I have created a simple system to allow users to create presentation style templates in Inkscape which can then be converted into, and used as, style templates for presentations in LaTeX. This provides a simple to use system for creating great looking, customised, PDF presentations. You can find the software at http://jedidiah.stuff.gen.nz/lpd.html.
On 3/6/06, Andrius Ramanauskas <knutux@...400...> wrote:
> I have already found out that /MacOS/Inkscape file is missing in
> Inkscape.app, and copying this file from installed Inkscape.app (0.43)
The file you want should be on the path src/inkscape . (See previous).
Whilst your approach eliminates one source of errors, I can't conceive
how a successful build could fail to produce an executable.
(You are using the same compiler as you used for Fink? If not your project
will not link - this is noted on the wiki page. You can find details
posts to this list and/or the bug tracker).
If the script is not copying the file, then there has to be something
wrong with it, or the instructions for its use. I don't deny that there is still
some little room for improvement, and any comments you have will
I am sure be taken most seriously.
> So I can now successfully contribute to the project. But had no time
> yet to investigate the cause of this problem with missing file.
O.K. I have to admit that most the time I run the unpackaged executable, and
have the support files installed with 'make install', like any other
it is rather fine to have a double-clickable bundle that starts X and launches
> On 3/6/06, Ben Fowler <ben.the.mole@...400...> wrote:
> On 3/4/06, Andrius Ramanauskas <knutux@...400...> wrote:
> > I tried to build Inkscape on Mac OS X 10.4, did everything as
> > described on wiki, it seems as everything succeed, but I get an error
> > "You cannot open the application Inkscape.app because it may be
> > damaged or incomplete" while running .app file.
> > Maybe anyone has run into similar problems and knows a quick solution?
> This may not be very helpful ...
> I compile Inkscape most days, and the process WFM, but I don't normally
> build the .app and .dmg. However, the last time I did (which may have
> been on Panther), it worked as
> per the documentation. So I haven't any insight into 'similar problems'
> and don't know a 'quick solution'.
> The error message means that the .app bundle was not made in its
> entirety, and I would suspect the package creation script,
> packaging/osx-app.sh or the documentation, but as I said above,
> don't take this too literally, as the process did work when I tried it.
> (If you are able to identify what is going wrong, I am sure that someone
> would be keen to fix the script or the docs).
> If you are raring to run Inkscape, and believe that you have a perfectly
> formed executable, then you can start X by hand and (provided that you
> have installed the share files and so forth - which you won't have done if
> had configured with
> ), you can start Inkscape by hand with a command line like:
> and it will work.
> Otherwise someone will have to upload (or create on sourceforge) a
> deliverable. The Inkscape.app is 93 MByte, and the .dmg (which is
> compressed is 22 MByte).
We've received a surprising number of donations lately - surprising in
the sense that we don't really solicit donations. I guess people just
love Inkscape *that much*. :-)
Anyway, for the record here's a breakdown of what's been received
Mar. 3, 2006 Payment Inkscape Project $18.06 USD
Feb. 27, 2006 Payment Inkscape Project $3.59 USD
Feb. 18, 2006 Transfer Bank Account $2,000.00 USD # Google SOC
Feb. 13, 2006 Payment Inkscape Project $8.48 USD
Feb. 13, 2006 Payment Inkscape Project $18.26 USD
Feb. 8, 2006 Payment Inkscape Project $3.59 USD
Jan. 2, 2006 Payment Inkscape Project $18.06 USD
Jan. 2, 2006 Payment Inkscape Project $8.38 USD
Balance: #2,474.99 USD
For a while now, there has been a struggle between those of
us who want testers to send us full Gdb backtraces, and people
who need smaller files to download over their connections.
I have been working on a compromise between the two:
1. Separating out the debug symbols into a file named inkscape.dbg,
and then stripping inkscape.exe . This takes longer to link, but it
preserves all of the debug symbols.
2. For each .exe that we place on a download page, we also provide
a compressed copy of its corresponding .dbg file.
Now testers do not need to download those many MB of symbols every
time, but when a bug happens, they can download the .dbg, do a backtrace,
and send the info to us. Now the difference between the 'stripped' and
'unstripped' versions of the builds need only refer to the accompanying
not the Inkscape executable itself.
I committed the makefiles already, and I'm uploading
Inkscape0603021243.zip and Inkscape0603021243-dbg.zip.
Hope this can help alleviate some of the confusion. I'll post some info on
how to use gdb with the .dbg file.