Re: Print plug-in
Hi, Same impression here. I can't remember that I installed Gnome on my desktop. And although I use Gimp for a long time now I never got the impression that I was working with Gnome. Eeek, even if we we use gnome-libs you will not have to install Gnome on your desktop. People should have never started to call GNOME a desktop environment, since that's only a small part of it (and not the most important one). I can't really see why people argue about KDE - GNOME since both projects don't follow the same goals. Of course I read on the Gnome-Office-site that Gimp would be part of Gnome-Office. Well I was quite surprised to read that as I didn't see any discussions about this topic here. It was a reason enough for me to ask the organisators of the GNOME developers conference why they didn't invite GIMP developers. Well, now they did and Mitch and me will be in Paris next month to see how GIMP may benefit from GNOME. UI in the 1.3.x devel series, so maybe then everyone will have a better opportunity to evaluate the dependencies of Gimp. That would enable a _sensible_ kde frontend, and most probably a cool perl interface for web-servers and the like ;) IMHO having two different UIs to perform the same task is a stupid idea. Why would people using KDE as their Desktop environment want their own GIMP as long as the one GIMP works well for them? It might be a good idea however to build different apps on the gimp-core. A small icon-editor, an animation-studio, ... Salut, Sven
Re: Plugins at Sourceforge
On 1 Feb, Kelly Lynn Martin wrote: additional plug-ins. Some things, like translations, must be part of the distribution currently. This needs to be fixed. :) Do you volunteer? I don't understand translations at all. :) What a pity... I'm currently trying to dissolve all these problems but while I coding some source I stumbled over a problem with gettext which took me nearly a whole to identify. I would really like someone to give me a helping hand on this to reduce the time and of course I would need someone to wake up Ulrich Drepper because I really need his answer :)) -- Servus, Daniel
Re: Print plug-in
On 1 Feb, Sven Neumann wrote: You don't seem to be very familiar with gnome-libs, especially not with the progress that was/is being made towards the next release. Uhm, not quite except that I'm trying to compile it every three days... gnome-print for printing (preview, native printer drivers, a nice print dialog) Optionally, OK gnome-fontfor font-rendering (don't know if gnome-2.0 will have this) I doubt that this would be of any real use, we want to have first class rendering into GIMP with no eye on speed and such opposing to the font-rendering of applications where rerendering happens quite often... gnome-canvas for the UI (he draw routines we use on the gimp canvas are very difficult to handle, using objects that can be connected to and emit signals would make our live much easier) I didn't really get your point here libartprovides convenient and optimized functions for all sorts of affine transformations Okay, I wouldn't even mind to make libart mandantory... gdk-pixbuf image-loading and simple (but fast) transformations (we may want to use this to implement a proper brush and patterns system since it integrates nicely with libart which would give us scalable, rotatable brushes/patterns for free) Optionally this would be okay, although I prefer Rastermans Imlib2... It may be that gdk-pixbuf focuses too much on the needs of a desktop or were there any other reasons to go away from Imlib? gconf for configuration (have a look into the code for the preferences-dialog, it sucks badly ...) I think the preferences dialog is very nice, anyway I'd prefer using XML as a save format for configureations and even for scripts. This would make macro recording possible... But having a centric configuration possibility for GIMP doesn't make any sense to me anyone out there who would like to configure it via GNOMEs control-center or via console? :)) gtkhtml seems to be a very nice replacement for gtkxmhtml ... Okay, for the help system... optional Now, tell me why we should recode all this on our own. It would not only be ridiculous to do so, I can also assure you that it is beyond our limits due to limited resources of good developers willing to spend their time to do it. I don't think we should avoid using new technologies for every price but we should avoid linking against megabytes of libraries just for having a possibility to print or render a nice UI On the other hand, a lot depends on the GNOME people. I hope that their goal is to provide a bloat-free set of portable libraries that don't depend on too much other stuff we don't want to use. We'll see -- Servus, Daniel
Re: Plug-In manag(er|ing)
On 31 Jan, Marc Lehmann wrote: BTW: we need to consult a ~/.gimp/po/ directory for translations as well at some point in the future! Bad luck, I don't know why you like to have a personal catalog directory but with gettext you have either ... or ... and setting up such a system which uses a personal catalog AND a global one would be a bit difficult... -- Servus, Daniel
Re: Print plug-in
On Tue, 01 Feb 2000 13:19:03 +0100, Torsten Rahn [EMAIL PROTECTED] said: Of course I read on the Gnome-Office-site that Gimp would be part of Gnome-Office. Well I was quite surprised to read that as I didn't see any discussions about this topic here. GNOME claims GIMP as part of GNOME because GIMP is better than any of the existing GNOME apps. They're trying to piggyback on our success. Personally, I think this is odious, but hey... Kelly
Re: Print plug-in
On Tue, Feb 01, 2000 at 01:45:22PM +0100, Sven Neumann [EMAIL PROTECTED]
wrote:
IMHO having two different UIs to perform the same task is a stupid idea.
For example, you want cutpaste under both desktops. And kde has cooked
their own incompatible clipboard system.
Why would people using KDE as their Desktop environment want their own
GIMP as long as the one GIMP works well for them?
It'd save memory a lot ;)
It might be a good idea however to build different apps on the
gimp-core. A small icon-editor, an animation-studio, ...
I also talked about a library. Unfortunately, many people try to use gimp as
computing server, with overwhelming success ("it even works some of the
time"). Many (not the majority) of perl users would like to have some
non-ui library thing to call into (that doesn't require X, doesn't require 7
seconds to start, can be embedded into applicaitons..)
I mean, there _are_ reasons why the UI/Core seperation has such a high
priority on our list ;)
will want to have one common GIMP UI. If there's something we can do to
integrate GIMP better with KDE, I'd love to hear about it.
It has been mentioned only countless times ;) The to-be-done-anyway
ui/core seperation is the time where kde people can code their own
frontend without feeling bad.
That means that we just need to follow our plan, which should make them
happy automatically.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: Print plug-in
XML as a save format for configureations and even for scripts. This would make macro recording possible... Macro recording and XML are two *completely* orthogonal things. Macro recording gets possible by programming it, not by using a difefrent format to save config files. I wonder where people get all their funny ideas about XML lately... GNOMEs control-center or via console? :)) Console, yes! But not using gnome ;- I don't think we should avoid using new technologies for every price but we should avoid linking against megabytes of libraries just for having a possibility to print or render a nice UI Indeed, as was said already: most of the gnome stuff does not have much to do with gnome, except that there are artificial dependencies to gnome. As seperated entities they would be much more useful (even if _named_ gnome). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Print plug-in
On Tue, 1 Feb 2000, Kelly Lynn Martin wrote: On Tue, 01 Feb 2000 13:19:03 +0100, Torsten Rahn [EMAIL PROTECTED] said: GNOME claims GIMP as part of GNOME because GIMP is better than any of the existing GNOME apps. They're trying to piggyback on our success. Personally, I think this is odious, but hey... GNOME claims GIMP as a part of GNOME because it really *should be*. As desktop agnostic as GIMP pretends to be, it requires all the same things the GNOME requires, and can't be configured through any of the standard mechanisms for those things (the GNOME people were gracious enough to make GTK themes in such a way that they apply to GIMP, but they can't do much other than that -- dialogs and buttons in GIMP will never look quite 'right' on any desktop.) GIMP, after all, spawned GNOME -- if it weren't for GTK, GNOME probably never would have been started in the first place. GNOME extended the rather clean and well-designed UI of the gimp into an entire desktop environment. I'm sure that many folks at Adobe think that what you're doing is 'odious' too -- just 'piggybacking' on photoshop. Let's keep in mind what side of these lines we're on.
Some UI inconsistencies and a patch....
Hiho developers... I discovered some name glitches in GIMP. 1. The "Settings" in the preferences Dialog wasn't in everything and is useless nevertheless because a preferences dialog is supposed to contain settings... 2. Some tools had a "Tool" in the options dialog and some not. Since all tools are tools and people know what tools are, we don't need to call some tools additionally tools :)) 3. The optiondialog of the tools is obviously a option dialog and nothing else so removing the "Option" is sensible and matches the behaviour of the professional programms A patch for fixing that is included -- Servus, Daniel diff21.gz
Re: Print plug-in
On 1 Feb, Marc Lehmann wrote: Macro recording and XML are two *completely* orthogonal things. Macro recording gets possible by programming it, not by using a difefrent format to save config files. You could use XML for saving macros. Of course you could also use scheme BUT: There are libraries e.g. libxml which allow very simple loading and saving of XML files while we would possibly have to write one for any other language first. It's a big advantage if you already have a parser/creator handy -- Servus, Daniel
Re: Print plug-in
On Tue, 1 Feb 2000 13:15:17 -0600 (CST), Tim Mooney [EMAIL PROTECTED] said: I agree that would be the best solution, but I'm afraid it's not that easy. I've submitted quite a few very small portability patches against ORBit from as far back as the 0.3.X days, and virtually every one of my patches has been rejected. I reported a "secret dependency" in ORBit on popt 1.4, and provided a simple patch. It has been ignored, and now Quartic is accusing me of "spreading FUD" even though I've clearly and publically documented that this dependency is NOT FUD. Nobody at GNOME appears even interested in pursuing this problem (which is quite subtle and evidence of very poor concern for portability); the only reason I can think of for this is that popt is universally present on Red Hat machines because it's part of RPM. Kelly
Re: Print plug-in
On Tue, 1 Feb 2000, Kelly Lynn Martin wrote: On Tue, 1 Feb 2000 19:09:14 +0100 (MET), [EMAIL PROTECTED] (Raphael Quinet) said: This statement is ridiculous. They are not claiming that they wrote the GIMP. They just state that it will be included as part of the Gnome-Office suite. You'd think they talk to the GIMP developers before making that claim, no? No, and it's their right not to. If you believe this should be a requirement, it should be part of the license. GIMP is a part of Red Hat Linux, why shouldn't it be a part of the GNOME office suite? If I recall correctly, GIMP is licnsed under the GPL, which means as long as the developers provide the source code changes that they make, they can make the GIMP a part of anything they damn well please. Too many people use this license without understanding (or considering fully) what it means... --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu
Documenting the source?
Hi developers, Having no real documentation of the sourcecode is really a burden when searching for bugs. Do you agree that having a documentation would be fine? I'd like to introduce a in-source-documentation which an extractor program could use to make a TeX or HTML file of it. Using javadoc like comments we'd always have a specification of a function handy without having to guess the sense. -- Servus, Daniel
Re: Usage of Gnome libs (was: Re: Print plugin)
On 1 Feb, Sven Neumann wrote: This is supposed to be first class font-rendering and if it prooves to be useful, I see no reason not to use it, even it has gnome printed on it. Well, if it really is first class rendering, then I'd like to see it in GIMP I haven't yet seen this package, is it in the CVS? gnome-canvas for the UI (he draw routines we use on the gimp canvas are very difficult to handle, using objects that can be connected to and emit signals would make our live much easier) I didn't really get your point here Look into the code that handles the bezier_curves UI. A good part of that code is doing nothing but checking if the mouse is on a control-point. Now imagine the control-points were objects that emit signals like enter, leave, clicked etc. Do you start getting my point? Now I do but AFAIK gnome-canvas is a fixed part of gnome-libs, or am I anybody working on seperating it? Okay, I wouldn't even mind to make libart mandantory... Why? libart was developed explictely to work w/o gnome-libs. It's an extremly useful library that fits perfectly to our needs. Uhm, maybe I just can't get no real English sentence out of my keyboard, in other words: Okay, go for it, link it to the GIMP :)) Optionally this would be okay, although I prefer Rastermans Imlib2... It may be that gdk-pixbuf focuses too much on the needs of a desktop or were there any other reasons to go away from Imlib? All I know about Imlib2 is that is has a lot of features we will never need. For example? Everything that is in Imlib2 so far would be also usable for the kind of actions you mentioned I don't see why gdk-pixbuf looks desktop-centric to you, That's my conclusion from the GNOME team wlaking away from Imlib and Imlib2... why else should they do that? but it certainly has a small memory-footprint, is fast and it integrates nicely with GTK+. GTK+? You meant gdk I guess and so does Imlib as well I think the preferences dialog is very nice, anyway I'd prefer using XML as a save format for configureations and even for scripts. This would make macro recording possible... But having a centric configuration possibility for GIMP doesn't make any sense to me anyone out there who would like to configure it via GNOMEs control-center or via console? :)) Did I say control-center? gconf is the new replacement for the control-center Daniel, this is FUD! You talk about using XML. Sven, gconf uses gnome-xml for storing preferences data, and that's something I really like about it Do you want to write your own parser? Why? It's already there... and I really like the idea of getting away from our current system... I'm not advertising gnome-conf since I don't know much about it, I just mentioned it as an example of stuff that might be of interest. Well, gconf is designed as a general purpose configuration system which can use several backends for storing it's data and several frontends for modifying preferences. Let's argue about using GNOME. It does not make sense to turn your head only if something has GNOME written on it. I don't have anything against GNOME... I like it in fact because the whole desktop environment has a small memory footprint and is fast compared with KDE. But I really doubt it is good for ANY big project which is not really related to GNOME to depend on it And remember: this has nothing to do with the desktop, the control-center or whatever. All we are talking about is if we want to use selected parts of the libraries that evolved around gnome. The good thing about these libs is that they are maintained and integrate nicely with GTK+ and its object system. Great, then we're on the same side As said before, a lot depends on the will of the GNOME people to release those libs in small packages without throwing too much gnome-specific stuff into them. I think we would already use the canvas now if it would have been released seperately. (gnome-xml)- not sure if we will need this one I think this could be very useful With the execption of the canvas all this is AFAIK already available outside of gnome-libs. Sven, I don't really know why you are arguing against me; It really seems like we do have the same things in mind so let's spend our time on realising them -- Servus, Daniel
Re: Print plug-in
On Tue, 1 Feb 2000 15:11:13 -0500 (EST), Glyph Lefkowitz [EMAIL PROTECTED] said: No, and it's their right not to. If you believe this should be a requirement, it should be part of the license. GIMP is a part of Red Hat Linux, why shouldn't it be a part of the GNOME office suite? If I recall correctly, GIMP is licnsed under the GPL, which means as long as the developers provide the source code changes that they make, they can make the GIMP a part of anything they damn well please. Too many people use this license without understanding (or considering fully) what it means... You're confusing legal rights with moral obligations. Since you raised legal nonsense, though, it's technically illegal for GNOME to use the GIMP trademark for promotional purposes without a license from the GIMP Development Team. The GPL grants a software license in copyright; it does NOT grant any rights to any other property, intellectual or otherwise. Kelly
Re: Documenting the source?
On 2 Feb, Sven Neumann wrote: We have already brought up this issue lately and I think the conclusion was that we try to add documentation for libgimp before 1.2. Most certainly we will use gtk-doc with comments embedded into the source. Marc volunteered to write the necessary scripts to convert the info out of the PDB. What characters does gtk-doc use to introduce a comment? I like the idea of having javadoc like comments i.e. /** */ with some special tags because there are several programms out their which make beatyful documentation out of this and it's quite a standard solution... I volunteer to do some of this documentation... I have to get the sense anyway... :)) -- Servus, Daniel
Re: Print plug-in
On 1 Feb, Steinar H. Gunderson wrote: Well, we _do_ have gimp-perl available... Uhm, yes... With XML, we'd have to write _both_ loader and saver There are fantastic parsers available, no need to write any of those. -- with gimp-perl (or Perl-Fu, whatever name you like best), we'll `just' have to add some saving hooks into the PDB That's the hitting point, if you want to use perl or script-fu here you have to produce code for (possibly :)) highlevel languages which isn't quite simple. In my illusion at least making tags from events and the way back should be simpler... I don't really see why you'd want to have XML for this -- it just doesn't seem logical to me. XML is very abstract, you can do nearly everything with it (except saving images :))... the macrorecording feature was just a quick idea by me; originally my intend for XML in GIMP was using it as a save format for user options to get that ugly rc parser out of GIMP -- Servus, Daniel
Help! How to unsubscribe from list...
Sorry 'bout this, but I really am stuck trying to get off this list! -R.
Re: Some UI inconsistencies and a patch....
On Tue, Feb 01, 2000 at 08:09:01PM +0100, [EMAIL PROTECTED] wrote: 1. The "Settings" in the preferences Dialog wasn't in everything and is useless nevertheless because a preferences dialog is supposed to contain settings... Your: " CategoryNew File " Looks IMHO much worse than the existing: " CategoryNew File Settings " 2. Some tools had a "Tool" in the options dialog and some not. Since all tools are tools and people know what tools are, we don't need to call some Same thing here. Just because all tools are tools there is no reason _NOT_ to display this. 3. The optiondialog of the tools is obviously a option dialog and Same here... Just because all these dialogs are option dialogs there is not reason not to display this fact. A patch for fixing that is included I detest :) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Print plug-in
On Tue, Feb 01, 2000 at 08:16:42PM +, "Steinar H. Gunderson" [EMAIL PROTECTED] wrote: You could use XML for saving macros. Of course you could also use scheme BUT: There are libraries e.g. libxml which allow very simple loading and saving of XML files while we would possibly have to write one for any other language first. Well, we _do_ have gimp-perl available... With XML, we'd have to write I first didn't understand you... but it now occured to me. The most natural save format for macros is either python, perl or scheme or any other language ;) you like best), we'll `just' have to add some saving hooks into the PDB tracing hooks, think "strace" for gimp. That way the logulator (for example) could be implemented much cleaner. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Print plug-in
On Tue, Feb 01, 2000 at 02:58:29PM -0600, Tim Mooney [EMAIL PROTECTED] wrote: In most cases, the response was along the lines of "your compiler is broken, it builds and works fine for me". Hey, that's exactly the same argument kde people used to use ;- BTW, I enjoy this flamewar very much, not because it's reasonable, but because I am proud of being a gimp (= not gnome) developer. I might be proud to be a gnome developer (if I were..), but not in this forum. "gnome", just like "kde" are very much political terms nowadays, and it's very nice to work on a projetc that just wants to be good, and is not generally linked to some political term (even if the gnomekde communities themselves might feel the same). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: installing .po files in addition to .gmo files?
On Tue, Feb 01, 2000 at 09:12:31PM +0100, [EMAIL PROTECTED] wrote: users want translated plug-ins! wether they come with the gimp or not. Well, yes, but I guess they wouldn't want to translated them themselves, so why personal i.e. with catalog in the home directory? Because it's the only user-writable place on a machine. I only talk about installing plug-ins _seperately_ from the gimp. The reason for a personal translation file is the same reason as for a personal brushes, plug-ins and session files... GIMP itself uses two and a plugin uses also two. So this means there is no problem, no? That would be possible... you can even use the .mo files which are (gmo == mo, I assume, since I have no idea what I am talking about all the time ;) If that's possible (which commands do I need), then there would be no need to deliver the .po files. However, the .mo file format is not standardized, so I doubt that it is possible to idsassemble them portably. you can use gettext... the only drawback: This would imply that all users have the gettext package installed... I think it's not too unreasonable to requre gettext for installing plug-ins. It's a bit awkward when you only want to install binary plug-ins, but since gettext itself is rather inadequate I don'T aim for the perfect solution, just something that works. (I estimate this to be under 3MB diskspace) yes. we could even compress them... That would require yet another dependency to a compression library/program that might not be available. OTOH, we might just as well require gzip, since the plug-in packages are most probably packed with it anyway. Daniel, do you know how to modify the Makefiles to do that, and where a good place to store these files is (probably just besides the .mo files)? There must be a simple way to find them though (a gimptool switch, maybe)? Sven?? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: bug in app/gimpdrawable.c
The function gimp-drawable-type-with-alpha wasn't completely guarded. Calling it with a non-existent drawable would cause a crash. We force a crash in that place (by using a g_assert) since something has gone wrong. With your patch we would return a perfectly valid image_type and gimp would continue, but a few function calls later it would certainly crash. I have inserted a few more g_return_if_fail (GIMP_IS_DRAWABLE (drawable)) and friends which should help to locate problems early. Salut, Sven
Re: bug in app/gimpdrawable.c
The function gimp-drawable-type-with-alpha wasn't
completely guarded. Calling it with a non-existent
drawable would cause a crash.
The fact that you can feed gimp with a bad drawable through the PDB and
make it crash, is indeed a bug. I have looked into the code in
app/drawable_cmds.c and I wonder why the validity of the passed
drawable_ID is not always checked. This code is autogenerated and it
looks that the check is disabled by default and is only enabled for
a few of gimp_drawable_ PDB calls.
Yosh, is this intentional? Otherwise please apply the attached patch
which makes all PDB calls check the validity of the drawable_ID.
Salut, Sven
Index: drawable.pdb
===
RCS file: /cvs/gnome/gimp/tools/pdbgen/pdb/drawable.pdb,v
retrieving revision 1.19
diff -u -r1.19 drawable.pdb
--- drawable.pdb 1999/12/26 07:54:39 1.19
+++ drawable.pdb 2000/01/31 17:35:00
@@ -20,13 +20,11 @@
sub drawable_arg {{
name = 'drawable',
type = 'drawable',
-desc = 'The drawable',
-no_success = 1
+desc = 'The drawable'
}}
sub drawable_coord_args {
@inargs = ( drawable_arg );
-delete $inargs[0]-{no_success};
foreach (qw(x y)) {
push @inargs, { name = "${_}_coord", type = '0 = int32',
@@ -104,7 +102,6 @@
{ name = 'undo', type = 'boolean',
desc = 'Push merge to undo stack?' }
);
-delete $inargs[0]-{no_success};
%invoke = ( code = 'drawable_merge_shadow (drawable, undo);' );
}
@@ -130,7 +127,6 @@
{ name = 'fill_type', type = 'enum GimpFillType',
desc = 'The type of fill: %%desc%%' }
);
-delete $inargs[0]-{no_success};
%invoke = ( code = 'drawable_fill (drawable, (GimpFillType) fill_type);' );
}
@@ -214,8 +210,6 @@
$outargs[0]-{desc} = "The drawable's image";
$outargs[0]-{init} = 1;
-delete $inargs[0]-{no_success};
-
%invoke = (
code = 'success = (gimage = drawable_gimage (drawable)) != NULL;'
);
@@ -226,8 +220,6 @@
drawable_prop_proc("the drawable's type", 'type', 'enum GimpImageType',
'type', "The drawable's type: { %%desc%% }");
-
-delete $inargs[0]-{no_success};
}
sub drawable_has_alpha {
@@ -425,7 +417,6 @@
drawable_arg,
std_image_arg
);
-delete $inargs[0]-{no_success};
%invoke = ( code = 'gimp_drawable_set_gimage (drawable, gimage);' );
}
@@ -461,7 +452,6 @@
desc = 'The thumbnail height',
alias = 'req_height' }
);
-delete $inargs[0]-{no_success};
@outargs = (
dim_args,
Re: Colormanagement
Hi, I'm Marti Maria, lcms author. I am glad my package is worth of your attention, so I would like to clarify some points. The library is under GNU Lesser license agreement, and it will remain under LGPL. There are some sentences in the web page about you can do whatsever you want, well these was from first release, when no license was required at all. I will remove those sentences when next revision, in a couple of days. I did choose LGPL, because it permits to incorporate the code in commercial projects, then, I guess, you can also incorporate it in any free project like GIMP if you like. About porting the engine, well, the code has conditional #defines for using assembler, fixed-point, or a more generic floating point implementations of key routines. Only a few functions like fixed to float and fixed mult/div must be provided. The fixed-point C-only version delivers 80% of asm speed, even more if the compiler is smart enough to optimize properly. Since a lot of people is interested in the engine, I have little time for now in porting to ANSI-C (wich code is definitively NOT) I belive an experienced programmer would finish the port in a couple of days, and I signup if my modest help is required, So, any volunteers? Regards, Marti Maria
Re: Print plug-in
Thus spoke Robert L Krawitz From: Sven Neumann [EMAIL PROTECTED] IMHO having two different UIs to perform the same task is a stupid idea. Actually, it's an eminently sensible idea. For KDE, having an image editing program that follows the KDE UI guidelines and all the other good stuff would be completely logical, especially since they wouldn't have to maintain the core, just the UI. But they wouldn't have to maintain anything if they just left the UI alone. I'm with Sven on this one. Two UI's accomplishes little. After all, the whole point of modern desktops is to personalize them, not make them all look the same. I like KDE and think they've done a good job with their desktop, but they shouldn't feel Gimp does't fit because it looks like GNOME. It doesn't look like GNOME. GNOME looks like Gimp. No chicken and egg problem here. What is important is that the application behaves well under session management under those environments. And, if possible, some drag and drop. Changing the UI is a lot of misplaced effort. The basic idea here is consistency. Look at it from the standpoint of someone just coming over from Windows: why should the Gimp work differently from all of their other KDE apps, which work consistently? Because it can. A little wave in the pond adds depth to a smooth surface. "Linux doesn't dictate how I work, I dictate how Linux works." Interesting sig, considering you're argument about uniformity in user interfaces. -- Michael J. Hammel | Any sufficiently advanced technology is The Graphics Muse | indistinguishable from magic. [EMAIL PROTECTED] | - Arthur C. Clarke http://www.graphics-muse.com
Re: Colormanagement
On 1 Feb, Martí María wrote: So, any volunteers? This piece of code is highly interesting but since this won't make into GIMP before 1.2 because of the featurefreeze I really hope that all GIMP developers will concentrate on the project until we released the next stable version. -- Servus, Daniel
Re: Print plug-in
On Tue, Feb 01, 2000 at 09:44:47AM -0700, Michael J. Hammel wrote: But they wouldn't have to maintain anything if they just left the UI alone. I'm with Sven on this one. Two UI's accomplishes little. The point is not just KDE vs. GNOME, is it? Isn't BeOS doing their own port of GIMP, using the native widget set? And I'm sure Windows users would appreciate a more-or-less native Windows UI, too. The basic idea here is consistency. Look at it from the standpoint of someone just coming over from Windows: why should the Gimp work differently from all of their other KDE apps, which work consistently? Because it can. A little wave in the pond adds depth to a smooth surface. I don't really get your argument here. Are you saying that `KDE is wrong, so we shouldn't integrate GIMP into it', or just `variety is the spice of life'? Remember, we're doing this for the end users, and end users will probably want the same UI everywhere, no matter if they've chosen KDE, GNOME or Win32. /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
Re: Print plug-in
On Tue, Feb 01, 2000 at 06:22:35PM -0500, Kelly Lynn Martin wrote: The KDE v Gnome issue is somewhat specious, but the Windows issue is not. Using Windows native UI functionality would probably result in a stabler, faster program as well as a program that users will understand better. The folks at Netscape manage to make this more or less work. We should be able to as well. But hasn't Mozilla basically given up on this idea and just used their own toolkit? Mozilla certainly looks crappy on the Mac at any rate. -Shawn -- Shawn T. Amundson [EMAIL PROTECTED] Research and Developmenthttp://www.eventloop.com/ EventLoop, Inc. http://www.snorfle.net/ "The assumption that the universe looks the same in every direction is clearly not true in reality." - Stephen Hawking
Re: Print plug-in
On Tue, 1 Feb 2000 17:24:35 -0600, "Shawn T . Amundson" [EMAIL PROTECTED] said: But hasn't Mozilla basically given up on this idea and just used their own toolkit? Mozilla certainly looks crappy on the Mac at any rate. I was referring to the commercial Netscape product, rather than Mozilla. I can't speak to why Mozilla made the decision to use their own toolkit. Kelly
Re: Print plug-in
From: "Michael J. Hammel" [EMAIL PROTECTED] Date: Tue, 1 Feb 2000 09:44:47 -0700 (MST) Thus spoke Robert L Krawitz From: Sven Neumann [EMAIL PROTECTED] IMHO having two different UIs to perform the same task is a stupid idea. Actually, it's an eminently sensible idea. For KDE, having an image editing program that follows the KDE UI guidelines and all the other good stuff would be completely logical, especially since they wouldn't have to maintain the core, just the UI. But they wouldn't have to maintain anything if they just left the UI alone. I'm with Sven on this one. Two UI's accomplishes little. After all, the whole point of modern desktops is to personalize them, not make them all look the same. Exactly. And that's why I think it's reasonable to have other UI's for the Gimp.. The basic idea here is consistency. Look at it from the standpoint of someone just coming over from Windows: why should the Gimp work differently from all of their other KDE apps, which work consistently? Because it can. A little wave in the pond adds depth to a smooth surface. Why, FROM THE STANDPOINT OF USERS WHO WANT ALL THEIR APPS TO WORK THE SAME, should the Gimp work different from their other apps? "Linux doesn't dictate how I work, I dictate how Linux works." Interesting sig, considering you're argument about uniformity in user interfaces. Enforced uniformity in user interfaces? Hardly. However, if that's what the KDE folks want to do, that's between them and their users. It isn't stopping anyone from using any other interface. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Print plug-in
First, I am not a coder: I'd argue that except for gconf and MAYBE gnome-canvas none of this stuff belongs in GNOME at all; these are all very generic facilities that shouldn't depend on any of the IPC, desktop, etc. stuff. Otherwise we wind up with the same kind of confusion and versioning problems that Windows has suffered with for so long. THis is one of my big annoyances with GNOME currently: there's a lot of useful libraries that really have nothing to do with GNOME but which are not separately exported, forcing you to install all the junk you don't want to get the stuff you do. I think, from user point of view, and after reading a lot of mails (here and other lists), that the desktop projects could separate lot of things into libs, like the libs for images that currently exist, or libc. IIRC GLib is a step in this direction, was inside GTK or GNOME, now is a separate lib, and GTK too, was Gimp toolkit, now used in lot of places (correct me if I am wrong). If somebody is reading this, maybe the desktop coders could accept that their projects are becoming stupidly fat and should "atomize" (?) so others can reutilize code without bloating. Desktop should take the same approach than image apps, using libpng, libtiff, libungif, etc, and if a new format appears, a new lib is created, not made part of the image app. gnome-print? libprint! If a desktop needs things to use a lib, make an adapter, not a new lib (gnome-print uses libprint, and any other app can use libprint directly too, or via gnome-print). Well, now everyone code whatever they want. These are just ideas. :] Another idea, get a water pistol or a foam hammer and organize desktop / editor / unix family (BSD vs SV) wars. Everybody should participate, maybe that way everybody will realize that you can live with the rest. ;] GSR
Re: Print plug-in
On 1 Feb, Shawn T . Amundson wrote: But hasn't Mozilla basically given up on this idea and just used their own toolkit? Mozilla certainly looks crappy on the Mac at any rate. Not yet... at the moment it's possible to use even gtk or qt for the UI but they are slowly migrating to their own rubbish. It's possible simpler for them than to have an additional layer between the UI and the widget toolkit. Anyway, GIMP doesn't suffer from such ideas because we already HAVE our own toolkit for GIMP... and it even seems to work with windows... :) -- Servus, Daniel
