Re: [Gimp-developer] OSCon attendance
On Wed, 7 Jul 2004, Dave Neary wrote: > > Hi, > > Quoting Carol Spears <[EMAIL PROTECTED]>: > > On Wed, Jul 07, 2004 at 04:06:38PM +0200, Dave Neary wrote: > > > Part of the results of that is that the GIMP is > > > one of the candidates for the annual golden award (with a > > > large cash prize) which will be presented to the winning > > > project in Portland at the O'Reilly Open Source Conference > > > in a couple of weeks. > > awesome. > > We're a long way from winning - we're up against the Valgrind > guy, Pango, VideoLAN, GNU arch and a couple of other really > good projects. We have a shot, though. Heh, my vote is for Valgrind. :) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.2 and elusive detachable"tear-ablemenus"
On Tuesday 13 July 2004 06:24 am, Joseph Heled wrote:
> Your remark about "focus policy" sent me to the KDE control center - and
> yes, it is a focus problem of sorts. I was running with "focus strictly
> under mouse" (CC/Look & Feel/Window Behavior/Focus). When I Change that to
> "Click to Focus", the menu remains until the window focus is lost. Would
> you do me a favor and see under which policy you run and if you get the
> same problem if you switch to another policy? (actually all you have to do
> is to detach a menu and switch focus by clicking on another window).
>
> Still, the menu disappears after a focus lose and does not return. This can
> be either a KDE bug or GTK bug.
I have now tried both options ("focus strictly under mouse" and "click to
focus") in KDE 3.2.3 without problems: I can tear off menus and they receive
focus when under the mouse / I click on them (depending on the setting). They
do not disappear magically. In short: works perfectly.
I consider it unlikely that we will easily find the exact cause of the problem
(could be deep inside Qt), and even if we do, the fix could be non-trivial.
Depending on how much you want working tear-off menus (beside other
advantages of newer KDE versions), an update of KDE and/or Qt would therefore
still seem to be the easiest way to fix the problem. For instance (assuming
the worst possible outcome of an attempted KDE update), backing up my entire
system and doing a complete re-install would cost me approximately 12 hours,
maybe more, but not more than 15 hours. I guess that this is still nothing
compared to locating the problem and fixing it, but I could of course be
wrong (with both).
Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
David, > So say I open an image with a color profile, and then load a > second image with a different profile. If I now decide to do the > above, what do we do to the first image? how about attaching a profile to each image? Correction is then done using the individual image's profile and the application-wide monitor profile. This gives you a lot of flexibility in the use of different profiles and saves you from having to switch the workspace profile back and forth. >From my own research on the matter, the way it is done in most apps and CMS workflows seems to use three profile settings: 1. a monitor profile 2. a default image profile 3. a working space profile The meaning of the monitor profile is obvious. The default image profile is assigned to images that don't have an embedded profile. The working space profile is a kind of preferred colour space, such as the in-house space of a studio. The workflow is then as follows: When an image is opened, it is assigned its embedded profile, or, if there is none, the default image profile. The assigned profile is then compared to the workspace profile. If they are identical, nothing happens, since the image already is in the user's working space. Otherwise, the user is notified of the fact that the image profile differs from the working space profile and is asked whether she would like to convert the image to the working space or to maintain its original profile. For ease of use there should be a preference setting that defines a default for this dialog and allows it not to be displayed (e.g. "always convert images to working space"). Display correction is then done based on the profile that was assigned to the image (which could be the embedded profile, the default image profile, or, if the image was converted, the workspace profile). Here the working space is more of a preference setting, a colourspace that the user prefers to work in. It is not necessarily used in the display correction (only if it is made the image's profile). In addition there are usually functions to assign a different profile to an image (only changes the attached profile, but doesn't manipulate the image data) or to convert an image to a different profile (changes the profile and the image data). Hope this is of any use Stef an ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] preparing the 2.0.3 release
Hi, as announced earlier, we'd like to do a GIMP 2.0.3 release this weekend. There are only a few bugs left on the 2.0.3 milestone and some of them are probably rather low-hanging fruit. So if you have some spare time during the next days, perhaps you could have a look and fix some of these: http://bugzilla.gnome.org/buglist.cgi?&product=GIMP&target_milestone=2.0.3 Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.2 and elusivedetachable"tear-ablemenus"
Yes it is certainly a KDE problem. Both WindowMaker and twm gave the menu a decoration (i.e. a title bar). Google shows that several others has encountered the problem on KDE 3.0X, and tearoff is disabled (and commented out) in KDE 3.1. I wonder if they solved it in 3.2/3.3? Thanks for your all of you who has responded !! Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.2 and elusive detachable"tear-ablemenus"
Hi, Joseph Heled <[EMAIL PROTECTED]> writes: > Still, the menu disappears after a focus lose and does not > return. This can be either a KDE bug or GTK bug. > > gimp 1.2 (under gtk 1.2) has no such problem since the menu has its > own window, i.e.comes up with a title bar of it's own. The detached menus certainly get window decorations here (using sawfish) so this is most likely a bug in the KDE window manager then. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.2 and elusive detachable "tear-ablemenus"
Hi, Markus Triska <[EMAIL PROTECTED]> writes: > > I guess that if no one else has this problem, it is a kde problem. > > That would also be my guess. I've been using Gimp with KDE 3.[012] for some > time, and although I (contrary to you) never ran into anything that I knew > should work but didn't, there surely were moments that made me doubt the > cleverness of its focus policy. Gnome 2.6.(2, currently) works better for me > with regards to that, so I recommend that you give it a shot (if possible) > and see if the problem remains, to narrow down the range of imagined > possibilities. It should be sufficient to try a different window manager, you shouldn't have to completely switch your desktop to make that happen. But then, I don't know how closely the KDE window manager is integrated with their desktop. Excuse my ignorance, but what is the default focus policy on KDE nowadays? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
