Plug-In manag(er|ing)
Do you volunteer? No, but I did. I just created an almost empty plug-ins/gpim (on sourceforge), gpim = gimp plug-in manager (does anybody have a good expansion for "mel"? :) The first step for redistributable plug-ins is the plug-in layout specification: every plug-in is stored in a subdirectory with it's own name, or a subdirectory with it's name+version (when it was stored in a versioned tar file). Inside, we have the following structure (source package): xxx/po [optional] contains .pot files and .po files. I guess this is the common standard anmd will stay for some time. Every successor must be able to manage .po files in some way, and maybe we can manage this more intelligent (using, say, a translation server that collects .pot files from plug-ins and updates them, easing both translator work and programmer work. Hey, that could be web-based!). xxx/plug-in.def [mandatory] contains a description, version, type fetch information, status etc.. This would be a good candidate for an XML application, but I do not want to drag in eitehr XML::Parser nor gnome-xml, nor any other external reference. Maybe it gets similar to the PPM format. xxx/configure [optional] Can be used to generate the Makefile. Somehow we must communicate some gimp-settings to the plug-in, but setting GIMPTOOL and related envvars should suffice. xxx/Makefile (this must somehow get generated, of course) it should have some standard targets (make dist for example, for creating source distributions, and bindist for making a binary package). xxx/README [mandatory] a long description. Binary packages would look like: xxx/plug-in.def [mandatory] this would be similar to the source, except that it also contains architecture information (e.g. config.guess output), should be autogenerated form the normal plug-in.def xxx/lib [mandatory] contains the subdirs "brushes", "gradients", "modules", "plug-ins", e.g. a partial mirror of ~/.gimp, so plug-ins can create their own subdirectories by putting them here) xxx/po [optional] guess what xxx/README [mandatory] again.. Of course, if I forgot anything... now step 2, managing and distributing these things: for plug-ins on sourceforge this would be easy. Just educate the people about their plug-in.def and the common layout. Source and binary distributions would be uploaded to some common place (preferably), say download.sourceforge.net, or they reside at the place stated in the plug-in.def. The manager program would then fetch the plug-in.def of all plug-ins and would synthesize a common database at a common place (e.g. http://plug-ins.gimp.org/plug-in.db.gz). This database could be downloaded by gpim on the "end-user" side. The end-user could then select the package (getting a short description of what it is), or the README (which will be fetched via the net). Then he would have to choose between different versions (e.g. the latest stable and the latest experimental release) and any precompiled binary packages we happen to have. After that the package would be fetched (cd-rom, net..) and installed either as user-only or systemwide, and do any magic necessary to update the translation tables (if at all possible ;) BTW: we need to consult a ~/.gimp/po/ directory for translations as well at some point in the future! Here is an example of a plug-in.def file, for a binary plug-in (this draws heavily on the ppd format described in http://www.activestate.com/ActivePerl/docs/lib/site/XML/PPD.html) SOFTPKG NAME="GPIM" VERSION="0,1,0,0" TITLEGimp Plug-In Manager/TITLE ABSTRACTGPIM is a coonvinient tool to manage gimp plug-ins/ABSTRACT AUTHORMarc Lehmann [EMAIL PROTECTED]/AUTHOR IMPLEMENTATION CODEBASE HREF="GPIM-0.1.tar.gz" / DEPENDENCY NAME="gimp-perl" / INSTALL perl Makefile.PL ;; make ;; make install ;; /INSTALL /IMPLEMENTATION IMPLEMENTATION OS NAME="Linux" / ARCHITECTURE NAME="i686-pc-linux-gnu" / DEPENDENCY NAME="gimp-perl" / CODEBASE HREF="GPIM-0.1-i686-pc-linux-gnu.tar.gz" / /IMPLEMENTATION /SOFTPKG -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Translation inconsistency
Hi, as pointed out before, we have an inconsistency between the core and the plugins when it comes to the point if PDB blurb and PDB help should be translated or not. The situation right know is: In the core the short description and the longer help strings for the PDB functions are not marked for translation. This decision was made since the PDB help strings are considered to be targeted mainly at developers and script-writers. It would be a lot of work to translate them and even more work to get the translations correct and to keep them uptodate. So it was considered not to be worth the effort. In the plugins domain however we did not spend too much attention and have marked those strings for translation. Well, a lot of plug-ins don't give useful help strings, so the amount of work for the translators is not as large as it would be for the core. All those strings only ever appear in the GUI when using the DB-Browser. So, the question is, does it make sense to translate them and is it worth the effort? Removing the strings from the pot-file would reduce the number of messages in the gimp-std-plug-ins domain considerably. They might be useful on the other hand, but the same applies for the core PDB strings. I have no idea how to handle this. Just a few suggestions: (A) do nothing, ignore the problem (B) don't mark the strings for translation, not in the core, neither in the plug-ins (C) mark the core PDB strings for possible translation too Any ideas, comments anyone? Salut, Sven
Re: Translation inconsistency
On Mon, Jan 31, 2000 at 01:53:47PM +0100, Sven Neumann wrote: In the core the short description and the longer help strings for the PDB functions are not marked for translation. This decision was made since the PDB help strings are considered to be targeted mainly at developers and script-writers. It would be a lot of work to translate them and even more work to get the translations correct and to keep them uptodate. So it was considered not to be worth the effort. Sounds fine to me so far, biased as I might be Any ideas, comments anyone? I'll buy (B) -- we do not translate C keywords, variable names, or any other components visible only to the developer. Nor do we translate internal errors, bug reports or this list. Therefore to contribute effectively as a developer you have to learn English anyway. If you need to tell USERS something important then it should not be in these strings, you should rather write a paragraph for the GUM. (B) don't mark the strings for translation, not in the core, neither in the plug-ins Nick.
Re: Translation inconsistency
My vote: (B) don't mark the strings for translation, not in the core, neither in the plug-ins There is enough work for translators anyway, without having to translate stuff intended only for developers. --tml
Re: Print plug-in
GIMP's a lot lighter than gnome-libs. I would substantially oppose any serious dependence on gnome-libs in GIMP. Especially since gnome-libs appears to depend on a library that is only available if you have RPM installed. Kelly, please don't spread FUD. People build gnome-libs on Debian boxes, old broken Slackware boxes, FreeBSD, Solaris, and other beasts. What library are you talking about? I think the GIMP would gain a lot from using the core GNOME libraries; right now it has a lot of reinvented wheels as it is. Users are going to want a consistent desktop experience, so the GIMP should not stand out as a sore thumb. Mind you, all the user interface improvements that the GIMP team has done are excellent. It is much better than the 1.0 series. Keep up the good work, Federico
Re: Translation inconsistency
On 31 Jan, Sven Neumann wrote: (A) do nothing, ignore the problem (B) don't mark the strings for translation, not in the core, neither in the plug-ins (C) mark the core PDB strings for possible translation too Kick them -- Servus, Daniel
Re: Plug-In manag(er|ing)
On Mon, 31 Jan 2000, Marc Lehmann wrote: Do you volunteer? No, but I did. I just created an almost empty plug-ins/gpim (on sourceforge), gpim = gimp plug-in manager (does anybody have a good expansion for "mel"? :) Marc, what did you smoke :-) ? Nils -- Nils Philippsen / Berliner Straße 39 / D-71229 Leonberg // +49.7152.209647 [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- Edsger W. Dijkstra
Re: Plug-In manag(er|ing)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 "Nils" == Nils Philippsen [EMAIL PROTECTED] writes: Nils On Mon, 31 Jan 2000, Marc Lehmann wrote: Do you volunteer? No, but I did. I just created an almost empty plug-ins/gpim (on sourceforge), gpim = gimp plug-in manager (does anybody have a good expansion for "mel"? :) Nils Marc, what did you smoke :-) ? Why not make it the GIMP Plug-in Manager Project? ;-)) Bye, J - -- Jürgen A. Erhard eMail: [EMAIL PROTECTED] phone: (GERMANY) 0721 27326 MARS: http://JuergenErhard.tripod.com/mars_index.html Mesa - Free OpenGL API (http://www.ssec.wisc.edu/~brianp/Mesa.html) "Windows NT" is an acronym for "Windows? No thanks." -- Russ McManus -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Use Mailcrypt and GnuPG http://www.gnupg.org/ iEYEARECAAYFAjiWEqkACgkQN0B+CS56qs2b8ACfbsnqHhRhdQeidLvVG6E+fqi0 HEsAniRFvywl8OoCP+OLYBGrLlJFE+hw =bsgS -END PGP SIGNATURE-
Re: Print plug-in
On Mon, Jan 31, 2000 at 04:33:53PM -0500, Federico Mena Quintero [EMAIL PROTECTED] wrote: I think the GIMP would gain a lot from using the core GNOME libraries; Just to throw in my opinion: gimp is _NOT part of gnome, other than in a technical way, and I personally think it is important that it stays so. Dragging in gnome-libs would not change that officially, of course, but gnome-libs are vast, and installing them comes short of installing the whole gnome. That does not feel right. right now it has a lot of reinvented wheels as it is. Seems so. However, the most important jobs of gnome-libs are not dependent on any desktop, but rather belong into a toolkit or a package of its own (like html widgets or the canvas widget). Maybe non-gnome applications could take more advantage of already invented wheels if they were more readily available. (Since I was just told that I might sound offensive, be assured that I don't want to sound like I might sound, I'm just opposed to the idea of using gnome-libs in gimp ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins at Sourceforge
On 28 Jan, Michael J. Hammel wrote: Do you mean language locales? I'm not very familiar with working with multi-language issues, but I have wondered why this isn't handled by the plug-ins directly. Because it won't work entirely this way... localisation works for everything but the menues which are set up by GIMP at startup time not by the plugins... GTK supports internationalization, right? Errr, let's say: a little bit So shouldn't the plug-ins be responsible for the language issues? Yes, they SHOULD, but it's not possible, at the moment... -- Servus, Daniel
Re: Translation inconsistency
If you need to tell USERS something important then it should not be in these strings, you should rather write a paragraph for the GUM. (B) don't mark the strings for translation, not in the core, neither in the plug-ins It depends on what is meant by having something important to tell the users. If the information is just letting the user know how to do something or what a particular feature does this should be in the manual. If its a message as a result of a run time situation (input needed from the user, status message, or an error message) this should be translated based on the users specified language. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: Print plug-in
On Tue, Feb 01, 2000 at 01:32:38AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: 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. Maybe the right solution is to make a gnome frontend (just like a kde frontend) to gimp, _after_ the UI-core seperation. I really do not like the idea of requiring _loads_ of other libraries that need to be installed first. And gimp (IMnsHO) _should_ stay out of the desktop war as much as possible, so I find it relatively important _not_ to get the gnome label sticked to gimp. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plug-In manag(er|ing)
On Mon, Jan 31, 2000 at 11:32:00PM +0100, Nils Philippsen [EMAIL PROTECTED] wrote: sourceforge), gpim = gimp plug-in manager (does anybody have a good expansion for "mel"? :) Marc, what did you smoke :-) ? Name and Conquer :-) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Print plug-in
On 31 January, 2000 - Robert L Krawitz sent me these 4.1K bytes:
From the user's perspective The Gimp is part of GNOME. For 1.2 this
won't be really true, but only because of lack of development time to
handle the changes. Is there serious concern here that user's will
NOT want a GNOME-enabled Gimp in 2001 or 2002 when the 1.3 series
might reasonably be expected to conclude with a new stable release?
Yes. The user may not have the disk space to install GNOME, or may
choose to run fvwm or ctwm.
I use fvwm 2.3.x and I run gnome apps every now and then.. what's the
problem?
Or, for that matter, the user may not want the security holes that may
exist in gnome. Take a look at this:
[...]
Huh, it looks like I have open TCP ports courtesy of GNOME. That's
not very nice, now is it?
Corba stuff, you can tell ORBit to use Unix-domain sockets instead.
It defaults to using tcp-wrappers and there is an authentication method
used similar to the MIT magic cookies iirc..
echo "ORBIIOPIPv4=0" $prefix/etc/orbitrc to disable TCP and use
Unix-domain sockets instead.
/Tomas
--
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
Re: Print plug-in
On Tue, Feb 01, 2000 at 01:18:54AM +, Nick Lamb [EMAIL PROTECTED] wrote: From the user's perspective The Gimp is part of GNOME. For 1.2 this won't be really true, but only because of lack of development time to handle the changes. Maybe I am misinformed... I have a different impression, but since there is no central steering agency for gimp, we will never know ;) I suppose we might conclude that vendors will ship only KDE, in which I talked quite a bit about that with Kalle Dalheimer about "kimp". You (rightly) remember that the "official" plan is to seperate the gimp ui from the core. The KDE people would not at all be opposed to code their own gui. The reason for their hack (no one says kgimp was a reasonable design) was that they lack the developer power to help with the core/ui seperation. case maybe those wacky Qt people will show up again and threaten to code a replacement Kim*g*sh*p if we won't re-write Gimp in C++ :) We haven't ever seen a bad comment about kde here or on #gimp, for sure ;) The problem with this is that many people on the kde lists are 3133t3-type people, unlike with gnome (simply because kde is the perceived leader, which is of course bound to change soon ;) 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 ;) Regardless of what happens, I do not feel like a gnome developer at all, I don't even use gnome (much because of the same reasons I do not use kde). I am sure I am not the only one who feels more-or-less strongly that gimp != gnome. Nick: view it as a sign of quality... we are independent! But - back to 1.1.x coding! Unfortunately, it's more like "1.2 fixing" :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Translation inconsistency
(B) don't mark the strings for translation, not in the core, neither in the plug-ins BTW, _this_ is the solution 1.2 has (most probably) settled for. It depends on what is meant by having something important to tell the At the moment, it depends solely on wether it can be made to "work" in 1.2, and it simply cannot. In 1.3 we have lots of similar i18n problems to solve. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins at Sourceforge
On Mon, 31 Jan 2000 08:57:59 +0100 (CET), [EMAIL PROTECTED] said: 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. :) Kelly
Re: Print plug-in
On Mon, 31 Jan 2000 16:33:53 -0500, Federico Mena Quintero [EMAIL PROTECTED] said: Kelly, please don't spread FUD. People build gnome-libs on Debian boxes, old broken Slackware boxes, FreeBSD, Solaris, and other beasts. What library are you talking about? popt. If you read gnome-hackers you'd already know about it since I posted there about this problem. ORBit would NOT build on my old slackware box until I installed this undocumented library. GNOME has a _lot_ of problems that it needs to clean up before it's ready for prime time on anything other than relatively vanilla RH or Debian box. Kelly
Re: Print plug-in
On Tue, 1 Feb 2000 01:18:54 +, Nick Lamb [EMAIL PROTECTED] said: From the user's perspective The Gimp is part of GNOME. There's no good reason for users to have this perception, though, since the only relation GIMP has with GNOME is that GNOME uses GIMP's custom-developed widget set, and some of GNOME's developers are/were GIMP developers. Perhaps it is time for GIMP to move out of GNOME CVS. Kelly
Re: Translation inconsistency
On Mon, Jan 31, 2000 at 09:40:21PM +0100, Stanislav Brabec [EMAIL PROTECTED] wrote: I'm not happy to hear about (B). I have already translated hundreds and hundreds of such string and I don't: The question is, where is it trnaslated? You can't translate it in plug-ins, you need to trnaslate it in the programs displaying the strings, e.g. the DB Browser, the PDB Explorer or other tools. -- want to trash my work Hmm... I don't think we can make good use of it in 1.2. Maybe it would be best to preserve them for 1.3, when new ideas have a chance to get implemented? -- The reading is very interesting (and sometimes only reasonable explanation, what plug-in does), that there is good reason to have it translated. I think so. But the technical problems are too large _now_. I have one idea: make another po (or other) file and move traslations there. But it requires extra code for switching between two catalogs. Translators will first translate gimp-std-plugins and then, when they have enough effort, can translate gimp-pdb. hmm... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Print plug-in
In regard to: Re: Print plug-in, Michael J. Hammel said (at 9:55pm on Jan...: GNOME-enabled is one thing. GNOME-dependent is another. Requiring GNOME libs on non Linux platforms may not be appreciated. If GNOME dependency is added, a determination on the difficulty on getting GNOME libs on non-Linux platforms has to be made. Since I don't currently use GNOME (I don't happen to need the added functionality that it currently offers) I don't know much about how portable it's become. But GTK and Gimp, at least, run on lots of platforms. Maybe that means GNOME is also fairly portable. I've dabbled with building a lot of the gnome components on half a dozen different Unix variants, all with the vendor compiler (for added fun :-) ). gnome-libs has become relatively portable. Every point release generally includes a couple trouble spots (new instances of C++ comments or other stuff that gcc passes that most other compilers object to), but for the most part it's quite good. The big problem is ORBit, which gnome-libs and hence all of gnome requires. There are a number of dodgy areas and portability problems with it. Getting it to build on a non-Linux system is possible, but not trivial. I would imagine the "casual compiler" would just give up as soon as they hit ORBit. I suppose we might conclude that vendors will ship only KDE, in which case maybe those wacky Qt people will show up again and threaten to code a replacement Kim*g*sh*p if we won't re-write Gimp in C++ :) The world doesn't live just on Linux. Gimp runs on other platforms. Amen. :-) Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
