On Sun, Feb 06, 2005 at 09:58:27AM +0100, Marc A. Lehmann wrote:
On Sat, Feb 05, 2005 at 02:17:43PM -0800, Carol Spears [EMAIL PROTECTED]
wrote:
http://packages.debian.org/unstable/libs/libgtk2.0-0
i guess that apt is not so well named lately? maybe apt not to is
better?
$
On 06.02.2005, at 02:46, Hal V. Engel wrote:
I probably should have said that I believed that the problems I had
with GTK 2.4 were likely caused by the RPMs I was using (user local
bin) as I had not tried building it myself. So this is a SuSE 9.1
specific problem. There have been some rather
On Sunday 06 February 2005 02:21, Daniel Egger wrote:
On 06.02.2005, at 02:46, Hal V. Engel wrote:
I probably should have said that I believed that the problems I had
with GTK 2.4 were likely caused by the RPMs I was using (user local
bin) as I had not tried building it myself. So this
On Sat, Feb 05, 2005 at 11:17:09PM +0100, Sven Neumann wrote:
You asked if going to 2.6 would cause a problem for them, and they
indicated it would.
No, they didn't. They said that they have had problems updating gtk+
in the past. So far noone has expressed any actual problems updating
Hi,
Hal V. Engel [EMAIL PROTECTED] writes:
I have started building GTK 2.6.2 glib 2.6.2, pango 1.8.0 and atk
1.9.0 all installed without any apparent problems. GTK configures
with any problems but fails on the make with the following error
messages:
Hi,
Carol Spears [EMAIL PROTECTED] writes:
i am curious to see what changes having gtk+-2.6 bring to poor gimp.
many of the problems with the 2.4 fileselector get shoved off because of
this great thing called gtk+-2.6. can we see a screen shot or even
several of the new things?
There are
Hi,
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:
A thing to remember is that even when it is folded into the main
gimp binary it still needs special command line switches (otherwise
gimp will run into the same problems as mozilla/firebird etc. which
often have frontend shell scripts
From: Sven Neumann [EMAIL PROTECTED]
Date: Sun, 06 Feb 2005 14:48:03 +0100
Hi,
Carol Spears [EMAIL PROTECTED] writes:
i am curious to see what changes having gtk+-2.6 bring to poor gimp.
many of the problems with the 2.4 fileselector get shoved off because of
this great
Hi,
Robert L Krawitz [EMAIL PROTECTED] writes:
I thought it was supposed to allow actually typing in a filename?
The really bad point of the 2.4 file selector is that (at least as
far as I can see) it only allows selecting a file, not typing the
pathname (at least, I don't see any text entry
Hi,
Sven Neumann [EMAIL PROTECTED] writes:
The GTK+ 2.4 file-chooser already allows you to type in a filename
after you press Ctrl-L. In GTK+-2.6 however you just start typing and
navigate to the file using the typeahead feature of the treeview. You
will only sometimes need to use the Ctrl-L
From: Sven Neumann [EMAIL PROTECTED]
Date: Sun, 06 Feb 2005 14:57:59 +0100
Robert L Krawitz [EMAIL PROTECTED] writes:
I thought it was supposed to allow actually typing in a filename?
The really bad point of the 2.4 file selector is that (at least as
far as I can see) it
Hi,
Robert L Krawitz [EMAIL PROTECTED] writes:
That's terribly obvious :-( If the entry box isn't visible, how is
anyone to know that you can actually do this?
You can do that in all treeviews (at least all treeviews that set a
search column). This is something that the user has to be told
From: Sven Neumann [EMAIL PROTECTED]
Date: Sun, 06 Feb 2005 16:19:14 +0100
Robert L Krawitz [EMAIL PROTECTED] writes:
That's terribly obvious :-( If the entry box isn't visible, how is
anyone to know that you can actually do this?
You can do that in all treeviews (at least
Sven Neumann [EMAIL PROTECTED] writes:
The new GTK+ file-chooser can make use of gnome-vfs, if it is
available. I don't know about the details, but I assume that on win32,
a similar API exists and is probably used by win32 backend of the
file-chooser widget. The default behaviour of the
Hi,
Robert L Krawitz [EMAIL PROTECTED] writes:
Every other file dialog I've ever seen has a visible entry for typing
in a filename. It's not clear to me why there's any advantage at all
to not having it visible. It just seems like a gratuitous
incompatibility.
Well, this is the wrong list
On Sun, 06 Feb 2005 17:22:00 +0100, Sven Neumann [EMAIL PROTECTED] wrote:
That said, I would like to state that whatever happens in GTK+, is of
course our responsibility as well. After all it's the GIMP toolkit.
IMO we should work a lot closer with the GTK+ development team. If it
was me, the
Hi,
Michael Natterer [EMAIL PROTECTED] writes:
An alternative to implementing our own vfs would be to entirely
hide file handling from file plug-ins, for example by passing them
already opened GIOChannels which they would use to read/write.
It woud be easily possible to make the IO channels
On Sun, 06 Feb 2005 17:03:20 +0100, Michael Natterer [EMAIL PROTECTED] wrote:
An alternative to implementing our own vfs would be to entirely
hide file handling from file plug-ins, for example by passing them
already opened GIOChannels which they would use to read/write.
It woud be easily
Nathan Summers wrote:
For a long time the policy was that we used the most recent devel
branch release. When did that change? CVS HEAD is a little too
fast-moving, but I don't have a problem with using the latest devel
version, and I don't remember anyone else having a problem with it,
either.
On Sun, 6 Feb 2005, Michael Schumacher wrote:
Nathan Summers wrote:
For a long time the policy was that we used the most recent devel
branch release. When did that change? CVS HEAD is a little too
fast-moving, but I don't have a problem with using the latest devel
version, and I don't
Hi,
Nathan Summers [EMAIL PROTECTED] writes:
For a long time the policy was that we used the most recent devel
branch release. When did that change? CVS HEAD is a little too
fast-moving, but I don't have a problem with using the latest devel
version, and I don't remember anyone else having
Sven Neumann wrote:
Would you mind to explain what sort of problems that would be? If we
need special command-line switches, we can as well stick to the
current solution. As far as I know, the remote feature of mozilla
works by looking for a mozilla window in the current X session. I
don't see
Hi,
Roel Schroeven [EMAIL PROTECTED] writes:
Would you mind to explain what sort of problems that would be? If we
need special command-line switches, we can as well stick to the
current solution. As far as I know, the remote feature of mozilla
works by looking for a mozilla window in the
Hi,
just wanted to let everyone interested know that I started to add
code for color management to GIMP CVS. For now, all we have is a
configuration object that is supposed to be visible by the core,
modules and plug-ins. This is based on a patch that Stefan Dhla
mailed me last year. The next
Sven Neumann wrote:
Hi,
Roel Schroeven [EMAIL PROTECTED] writes:
Would you mind to explain what sort of problems that would be? If we
need special command-line switches, we can as well stick to the
current solution. As far as I know, the remote feature of mozilla
works by looking for a mozilla
Hi,
Roel Schroeven [EMAIL PROTECTED] writes:
What I mean is this: suppose you have a remote instance of the Gimp
running, and then you want to open a local file in the Gimp. I think a
new, local instance should start to open that file, since the remote
one can't load that file. But if the
Hi,
Nathan Summers [EMAIL PROTECTED] writes:
For a long time the policy was that we used the most recent devel
branch release. When did that change? CVS HEAD is a little too
fast-moving, but I don't have a problem with using the latest devel
version, and I don't remember anyone else having
On Sun, Feb 06, 2005 at 02:51:05PM +0100, Sven Neumann [EMAIL PROTECTED]
wrote:
Would you mind to explain what sort of problems that would be? If we
mozilla ./file
= file not acesssible (permission denied, other user, inaccessible dir)
= file not accessible (different machine)
= file not
On Sun, Feb 06, 2005 at 08:41:30PM +0100, Sven Neumann [EMAIL PROTECTED]
wrote:
Of course you can't load a local file into a gimp instance running on
This is, of course, possible, but not with the current gimp-remote, and
it's probably not that desirable t make it run.
a different machine but
On Mon, Feb 07, 2005 at 12:16:33AM +0100, Sven Neumann [EMAIL PROTECTED]
wrote:
new, local instance should start to open that file, since the remote
one can't load that file. But if the remote protocol just looks for a
gimp window, it will try to use the existing gimp instance to open the
On Sun, Feb 06, 2005 at 02:48:03PM +0100, Sven Neumann [EMAIL PROTECTED]
wrote:
keybindings have been added and some of the focus problems have been
eliminated. These changes improve usability of the file chooser a lot
and I think that it can now really be called an improvement over the
old
Hi,
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:
In some directories it takes the Save As dialog a verified 40
minutes to open.
You better file a bug report about this then or at least make sure
that there's one filed about it. There have been a couple of changes
that deal with exactly
On Mon, Feb 07, 2005 at 02:51:00AM +0100, Sven Neumann wrote:
Hi,
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:
Would you mind to explain what sort of problems that would be? If we
mozilla ./file
= file not acesssible (permission denied, other user, inaccessible dir)
= file
33 matches
Mail list logo
