Hi,
On Wed, 2008-05-28 at 12:47 +0800, cc wrote:
Can someone point out what's the point of this? As far as
I know and see, regardless of whether info-data-use_full_page
is true or false, the *page_width and *page_height are set
to the same thing.
Look again, the code in the if clauses is
Hello,
I'd like ALL GIMP windows (typicaly one named GIMP, window Layers,
window Brushes, window with edited images etc.) to be brought to the
front (of other non-GIMP windows), when an arbitrary of them is selected
(e.g. via Alt+Tab) or clicked on.
This behaviour seems to me better as you
Hi,
On Wed, 2008-05-28 at 08:55 +0200, Procházka Lukáš Ing. - Pontex s. r.
I'd like ALL GIMP windows (typicaly one named GIMP, window Layers,
window Brushes, window with edited images etc.) to be brought to the
front (of other non-GIMP windows), when an arbitrary of them is
selected (e.g.
Sven Neumann wrote:
Procházka Lukáš Ing. - Pontex s. r. wrote:
I'd like ALL GIMP windows (typicaly one named GIMP, window
Layers, window Brushes, window with edited images etc.) to be
brought to the front (of other non-GIMP windows), when an arbitrary
of them is selected (e.g. via
Von: Procházka Lukáš Ing. - Pontex s. r. o. [EMAIL PROTECTED]
I'd like ALL GIMP windows (typicaly one named GIMP, window Layers,
window Brushes, window with edited images etc.) to be brought to the
front (of other non-GIMP windows), when an arbitrary of them is selected
(e.g. via
Hi,
On Wed, 2008-05-28 at 09:41 +0200, Kurt Pruenner wrote:
That or the ability to scroll beyond the image's bounds (extending the
scroll bars to go half the width/height of the window beyond the image
edges) would make working a lot easier - I find myself constantly
resizing image windows
Sven Neumann wrote:
On Wed, 2008-05-28 at 09:41 +0200, Kurt Pruenner wrote:
That or the ability to scroll beyond the image's bounds (extending the
scroll bars to go half the width/height of the window beyond the image
edges) would make working a lot easier - I find myself constantly
Hi,
On Wed, 2008-05-28 at 09:41 +0200, Kurt Pruenner wrote:
(I guess an option to disable TAB to switch between controls in the dock
windows - which I personally never need, since I navigate the docks with
the mouse - isn't an option, is it?)
That is already possible using the existing
Hi,
On Wed, 2008-05-28 at 10:17 +0200, Kurt Pruenner wrote:
Still - would it be possible to make the function the TAB key currently
has remappable, like all the other functions that already are?
No, it can't be configured through the same mechanism as the menu
keybindings. And I don't think
Hi,
On Wed, 2008-05-28 at 09:41 +0200, Kurt Pruenner wrote:
It would be really nice to be able to work in fullscreen all the time by
just showing and hiding all dock windows when neccessary, but TAB ceases
to work as soon as some control in a dock has focus...
Tab only has this effect when
If you want to change the behaviour on Windows, then you should check how you
can contribute to GTK+. This is where window-management related problems are
supposed to be solved (for example, if the the always on top hint for docks
would work, then one big problem would be solved already).
One problem in implementing window manager hints and related things
correctly on Windows is the lack of exact specifications what they
should do, and a lack of *minimal* sample programs that could be used
to verify that the implementation is correct.
That said, at least the
12 matches
Mail list logo
