Re: s/ImageMagic//g

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: s/ImageMagic//g
by Boudewijn Rempt on Tuesday 21/Jun/2005, @13:41

Why? Is there something unclean about ImageMagick? Of course, if you are content with loading and saving nothing but native files, you can use Krita without ImageMagick already -- but I lack the resources to create import/export filters for all the formats that ImageMagick supports, and Krita needs more than kimgio can deliver.

Related Links

·   Articles on KDE Office Suite
·   Also by Boudewijn Rempt
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: s/ImageMagic//g
by other ac on Tuesday 21/Jun/2005, @14:26

Agree. I don't see the point of removing the dependency on ImageMagick. ImageMagick is ubiquitous and does just about every image format conversion you can think of.

[ Reply To This | View ]

Re: s/ImageMagic//g
by ac on Tuesday 21/Jun/2005, @16:35

I think the proper solution would be to have a image framework for KDE or something like that.

[ Reply To This | View ]

Re: s/ImageMagic//g
by Asdex on Tuesday 21/Jun/2005, @22:48

Why reinvent the wheel?
ImageMagick works. Just do it the unix-way instead of reinventing the wheel all the time.

[ Reply To This | View ]

Re: s/ImageMagic//g
by cies breijs on Tuesday 21/Jun/2005, @23:11

> Just do it the unix-way instead of reinventing the wheel all the time.

Or may this old-skool quote:

"Those who do not understand Unix are condemned to reinvent it, poorly." -- Henry Spencer, University of Toronto

Cies Breijs

[ Reply To This | View ]

Re: s/ImageMagic//g
by ac on Wednesday 22/Jun/2005, @09:33

I think both quotes are quite silly. If we argue why re-inventing the wheel then by now we all would still be using CDE. There is a problem we need to solve properly and this means a sane graphic layer library doing these kind of work. Right now we have different KDE applications using different versions of graphic libraries for doing exactly the same task. Some use libimlib, some use stuff from imagemagic, some other things use some other libraries and and and. We could get rid of a lot of dependency on 3rd party libraries and tools if there was a proper graphic library or something. All KDE apps that require such a library can use the one provided by KDE and not from any random 3rd party application. It's easier for bugtracking and easier to maintain too.

[ Reply To This | View ]

Re: s/ImageMagic//g
by D. Rollings on Wednesday 22/Jun/2005, @12:27

You know what I think KDE needs to standardize for all of us?

Datatypes. Small generic libraries dealing with specific media formats. Datatype-aware programs become forward compatible; compile a library for a new image type, and all programs dealing with images know how to use that file. Amiga OS 3.x did it, OS/2 Warp did it... what are we waiting for? I've been wanting datatypes for audio, 3D objects, image formats and more for a while! They show these MIME associations that Windows 95 somehow lowered our expectations to for the crude, inflexible constructs that they are.

And if a datatype has to call ImageMagick, big deal. It'd be a minimal chunk of code for the purists to revise later.

[ Reply To This | View ]

Re: s/ImageMagic//g
by ac on Wednesday 22/Jun/2005, @14:11

At least as standardized wrappers (in cases of ImageMagick and Xinelib etc.) this would be really a nice idea, possibly this could be done for KDE4. Did you suggest that at some central place already?

[ Reply To This | View ]

Re: s/ImageMagic//g
by D. Rollings on Monday 27/Jun/2005, @06:35

I have as of now. It looks as though the kfile and kimgio libraries certainly fill in the gap for images with a plugin architecture; at this point, I have a general interest in seeing whether this approach extends to other formats.

[ Reply To This | View ]

Re: s/ImageMagic//g
by Anonymous Gnome on Tuesday 28/Jun/2005, @11:14

between gdkpixbuf and gstreamer gnome has effectively done this for images and video but it was largely incidental and unfortunately not part of some greater plan. no reason why kde couldn't do one better.

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"Time for a make-it-cool branch?" -- Simon Hausmann
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.