Re: [Gimp-developer] UI remarks
On Thu, 7 Jun 2001, Federico Mena Quintero wrote: Agreed. Just pick a reasonable default based on the amount of memory in the system. And please use libgtop to figure that out instead of some horrid hack like cat /proc/meminfo. If we're going to depend on Yet Another Library, might I suggest that we at least use it more? For instance, we could make the tile cache dynamically resize itself depending on hom much memory is free. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: UI remarks
[EMAIL PROTECTED] (2001-06-08 at 0200.27 +0200): Also, it is bad that you have to know that ~/.gimp exists and that you may need to hand-tweak the stuff in there. Everything should be configurable through a nice graphical interface; if you need to install third-party plug-ins or scripts or gradients then the GIMP should have an install plug-in command. This command can simply copy a binary into your ~/.gimp/plug-ins. No, some people want to be able to hand-tweak stuff using an editor. That's why we have user-readable config files. Apart from that everything important is indeed configurable through the prefs. But I have to admit that it's probably a bit too much information for a user installation dialog. But I like the way we managed to integrate all the info from the 1.0 installation dialog into this page on the new one ;-) I hope he means user does not need to know it, not files should not be hand editable. One thing is about making life easier for some people, and the other making it painful for other people. BTW, last time I checked there was gimptool. OK, maybe it needs a GUI for some people. Also, in most cases you do not need, it is one of those FAQ's for [choose a name from the common list of 2D/3D apps]: I got a plugin, now what? Now move it to the plugins folder and restart the app. Which, to some point, is a good reason to make the user know that ~/.gimp-V/ exists. It is also the container for scripts, and people want to pass files to friends... gimptool --send-brush-to email ? ;] Message idea: The GIMP stores config info in ~/.gimp-V/ and has been created / as been created based in your previous config ~/.gimp-V-1/ (show the appropiate version). It is also the place to store user plugins, scripts, brushes. Feel free to browse the dir and fill it with the extras you create / download. (Expandind the abbrevs ;] ) I have not yet seen one X-Server giving a close to correct value here unless you manually tell it the correct value on start-up. Last time I tried XF4 (3.3.6 now, it was just a test) the logs shown the monitor size fine. It works if your card and monitor can talk DDC. Maybe some daily users of XF4 could report what is going now. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
On Friday, 8 Jun 2001, David Monniaux wrote: I've been trying to contact libpaper's author, but to no avail so far. libpaper is old (1996) and does not offer per-user paper formats. Furthermore it does not allow interactive modifications. But, we're talking about *paper* here. A4 for me is the same size as A4 for another user, surely? There are only a limited number of paper sizes in existence, and they should all be available system-wide. Maybe I don't really understand what you're trying to do. The PostScript Red Book has a section on media selection which describes how a PostScript interpreter picks the paper size/color/headed to print on. It might be useful. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-print-devel] ANNOUNCE: Gimp-Print 4.1.8
On Thu, Jun 07, 2001 at 10:01:40PM -0400, Robert L Krawitz wrote: 10) The Gimp plugin should now build on systems not using GNU make. Has anyone confirmed this? I never got any reply from the BSD users who had problems (I wanted ones Makefile.in, but he never sent it) and Murray never confirmed that my fixes worked (although I thought they were OK). -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ For GPG Public Key: finger [EMAIL PROTECTED] or see public keyservers. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
On Fri, 08 Jun 2001 19:37:38 David Monniaux wrote: On Fri, 8 Jun 2001, Austin Donnelly wrote: But, we're talking about *paper* here. A4 for me is the same size as A4 for another user, surely? There are only a limited number of paper sizes in existence, and they should all be available system-wide. That's not true. Users have things like that fancy letter paper that I buy at Flammarion, which have weird sizes. They have stickers, envelopes, and other things on which they want to draw logos. They also want to be able to do things like be able to print out multiple copies of the same image on a page with crop marks. This would be fairly similar to printing out out labels except that the size would be user defineable. But this is page layout it is not image manipulation putting this in gimp would mean you couldn't use it for other apps. It would be more usefull as a stand alone program and leave gimp with just the basic print plugin it has at the moment. Being able to set the canvas size easier would be a boon though. i.e a cd sized (and shaped) canvas. The paradigm could also encompass screen dimensions, like 16x16 icon or advertisement bar at top of MyStartup.com. In the future: We could also add things such as background color of the paper, or a default letterhead - the user could then place his or her drawing according to the background color or letterhead. Why then do we have a per-user unitrc? David Monniauxhttp://www.di.ens.fr/~monniaux Laboratoire d'informatique de l'École Normale Supérieure, Paris, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer rob ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
Hi, rob [EMAIL PROTECTED] writes: But this is page layout it is not image manipulation putting this in gimp would mean you couldn't use it for other apps. It would be more usefull as a stand alone program and leave gimp with just the basic print plugin it has at the moment. please bear in mind that the print plug-in already has some of this functionality. We should at least contact the gimp-print people and ask what thoughts they have already put into this and what they have come up with. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
From: Sven Neumann [EMAIL PROTECTED] Date: 09 Jun 2001 00:47:28 +0200 rob [EMAIL PROTECTED] writes: But this is page layout it is not image manipulation putting this in gimp would mean you couldn't use it for other apps. It would be more usefull as a stand alone program and leave gimp with just the basic print plugin it has at the moment. please bear in mind that the print plug-in already has some of this functionality. We should at least contact the gimp-print people and ask what thoughts they have already put into this and what they have come up with. I've read through these messages (at least since I noticed the comments about paper sizes), and I'm trying to understand exactly what problem people are trying to solve. I'm not familiar with libpaper, so I don't know what this is all about. Could someone fill me in? The print plugin (actually, the entire package) does support custom paper sizes, at least on printers that allow it; some printers don't allow it. However, there was this comment: But, we're talking about *paper* here. A4 for me is the same size as A4 for another user, surely? There are only a limited number of paper sizes in existence, and they should all be available system-wide. The physical paper size of A4 is standardized; the area that can actually be printed on varies by printer. Again, since I don't know what the problem is, I don't know whether this is an issue. -- 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 Gimp Print/stp -- http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI comment from an NT user
Raphael Quinet wrote: Yesterday, I wrote: Hmmm... Maybe I should re-post this as an article on Advogato? That's what I did. You can find the article here: http://advogato.org/article/287.html Some of the replies are interesting, even if they would be a bit off-topic for this list. -Raphael The article's comments are interesting and show that people are using MDI for at least 4 different concepts. - There is the Microsoft MDI API. I have not tried to use it in a program so cannot comment. - There is the window within window concept. StarOffice and Microsoft Works both open a window containing multiple windows. I do not like those instances of windows within windows because they group unrelated applications and documents together. I would rather have Word files in a group with RTF documents but not mixed with spread sheets or database files. - There is the multiple document in one window approach. Opera opens multiple web pages in one window so, while I prefer Opera to Netscape, I tend to open unrelated web sites in Netscape so each site appears as a separate selection in the main toolbar. The opposite is true for email, where having all email documents open in the one window lets me very quickly scroll through the junk mail. - There is the docked and undocked toolbar approach. I do not call a tool a document, but some people do, and some tools open complex windows that would qualify as documents in their own right. I like a document appearing with all the tools applicable to the document. Netscape does a nice job by letting read email within the email application window with all email application tools in the toolbar, or I can click on an email and have it open in a separate window with just those tools that relate to individual email. I like that approach and in PaintShop Pro (the release I use), simple tools stay docked, complex tools pop open an undocked settings window. While the PaintShop Pro approach of popping up windows is nice, there are multiple images in the window and the one setting always applies to all images. There are occasions when I want to apply the same action to all the open documents so having them all in one window with one setting the for tool is great. There are also occasions when I have open several groups of images, with each group containing several images (or dozens of images) and I would like a tool setting to apply to just one group. In that case I can open several instances of PaintShop Pro, have a group of images in each instance and set the settings individually. Unfortunately that release of PaintShop Pro uses one internal setting and a change to the settings in one instance will be used in all instances, even through the tool settings display continues to show the individual setting. As another instance of good and stupid programming, an abnormal termination of one instance of Netscape, will terminate all instances of Netscape while blasting away one instance of PaintShop Pro will leave all the other instances working happily. In Apache, a big change in release two, is to support both NT's tasking and multithreading so an administrator can run separate Apache tasks for reliability while using multiple threads for performance. It would be nice to have all applications that sophisticated so separate instances of Netscape can survive the failings of other instances and PaintShop Pro will not change settings in other instances of PaintShop Pro. Something I liked, back in the days when I was learning to tie shoelaces and program in Assembler (which is the easier of the two), OS/360 had what is effectively read only memory for applications. I know 98% of programmers, including most of IBM's, did not understand the concept, but it meant you could load an entire application in to memory, or just the frequently used bits, without executing the program, or using any variables, then reference the code from other tasks, The other tasks would then be extremely small and totally independent, as each would open it's own read/write memory for variables but have almost no code. Writing a well formed program was actually easier than writing the code typically sold by the big software companies. A 100,000 people could use well formed code at the same time and not have a single collision. I do not understand why companies like Netscape work so hard to make one instance crash other or why Jasc have one instance update other. Irrespective of the technology, I would like to open an image with it's own toolbar and settings while having a separate image open with separate settings, and, when I click on one image, have all it's tools and settings appear together. A second item, in the Windows toolbar, Netscape displays the document's title first then places the advert for Netscape second while Opera places the advert for Opera first and the document name second. Opera's approach is unbelievably frustrating with a crowded tool bar. Gimp places the document name
[Gimp-developer] ANNOUNCE: Gimp-Print 4.1.9
Gimp-Print 4.1.9 was released to fix a critical bug in 4.1.8. It will also use substantially less memory printing at high resolutions. There are otherwise no changes from 4.1.8. -- 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 Gimp Print/stp -- http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
On Fri, 8 Jun 2001, Austin Donnelly wrote: But, we're talking about *paper* here. A4 for me is the same size as A4 for another user, surely? There are only a limited number of paper sizes in existence, and they should all be available system-wide. That's not true. Users have things like that fancy letter paper that I buy at Flammarion, which have weird sizes. They have stickers, envelopes, and other things on which they want to draw logos. The paradigm could also encompass screen dimensions, like 16x16 icon or advertisement bar at top of MyStartup.com. In the future: We could also add things such as background color of the paper, or a default letterhead - the user could then place his or her drawing according to the background color or letterhead. Why then do we have a per-user unitrc? David Monniauxhttp://www.di.ens.fr/~monniaux Laboratoire d'informatique de l'École Normale Supérieure, Paris, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-Perl, Perl-Fu, Mandrake 8.0
On Fri, Jun 08, 2001 at 06:44:05PM -, [EMAIL PROTECTED] wrote: I'm attempting to use the Gimp-Perl interface with Gimp-Fu, my platforms are Mandrake 8.0 with the Gimp 1.2.1 installed from the it seems that mandrake-8.0 comes with a broken gimp-perl, but I am not sure what is atcually the culript. the wrokaround (compiling/installing it yourself) has worked fine so far. could you send me the output of this command: perl -MGtk -e 'print $Gtk::VERSION' thanks. maybe it's just the specific Gtk version that comes with mandrake that is gimp-pelr is stumbling over. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
David Monniaux [EMAIL PROTECTED] writes: I've been trying to contact libpaper's author, but to no avail so far. libpaper is old (1996) and does not offer per-user paper formats. Furthermore it does not allow interactive modifications. I think we should do something ourselves (maybe being compatible with libpaper for /etc/papersize). I don't know what file format to use: an obvious choice would be something like The gnome-print library already handles this for you. No need to reinvent the wheel. Federico ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
