1:03 a.m.
Jon,
Thanks for your work on toolbars. It will be nice to have the ability
to make them vertical. However:
- PLEASE describe your changes in Release Notes
- I think it would be even more useful to have the ability to put two
or more toolbars on the same horizontal or vertical strip, next to
each other. Will your refactoring allow for that?
- I assume the now-vertical snapping toolbar is more of a
demonstration - I really don't see much reason to single it out for
vertical placement?
- Still, I couldn't re-attach the snapping toolbar into a horizontal
position anywhere. It's either its original vertical position at the
right, or floating. And re-attaching it to the original position is
also quite difficult - the magnetic zone is very small. Can you affect
this or is this unfixable in GTK?
- Will you be able to block standalone floating state for toolbars? As
discussed many times, they sink under the main window which makes them
unusable.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
2:55 a.m.
OK, so it's not a refactoring effort :)
It looks like the new toolbar code crashes on 64-bit systems (I have
64-bit Ubuntu 9.10). Look at #7 in particular.
#0 0x00007fffefd153c1 in strlen () from /lib/libc.so.6
#1 0x00007ffff3833b92 in g_strdup () from /lib/libglib-2.0.so.0
#2 0x00007ffff40e2bbd in ?? () from /usr/lib/libgobject-2.0.so.0
#3 0x00007ffff5b7a532 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#4 0x00007ffff5b7aa0a in gtk_list_store_set_valist ()
from /usr/lib/libgtk-x11-2.0.so.0
#5 0x00007ffff5b7aae8 in gtk_list_store_set ()
from /usr/lib/libgtk-x11-2.0.so.0
#6 0x0000000000707202 in create_or_fetch_actions (
desktop=<value optimized out>) at ../../src/widgets/toolbox.cpp:849
#7 0x000000000070d614 in setupToolboxCommon (toolbox=0x2a869d0,
desktop=0xffffffff, descr=0x7fffffffd9a0 "",
toolbarName=0x7fff00000000 <Address 0x7fff00000000 out of bounds>,
sizePref=0x7fff00000000 <Address 0x7fff00000000 out of bounds>)
at ../../src/widgets/toolbox.cpp:1631
#8 0x000000000070073e in Inkscape::UI::ToolboxFactory::setToolboxDesktop (
toolbox=0x2a869d0, desktop=0x1b32c00) at ../../src/widgets/toolbox.cpp:1615
#9 0x0000000000733a41 in Inkscape::UI::UXManager::connectToDesktop (
this=<value optimized out>, toolboxes=..., desktop=0x1b32c00)
at ../../src/ui/uxmanager.cpp:98
#10 0x00000000006db3ea in SPDesktopWidget::createInstance (
namedview=<value optimized out>)
at ../../src/widgets/desktop-widget.cpp:1395
#11 0x00000000006db506 in sp_desktop_widget_new (namedview=0x7fff00000000)
at ../../src/widgets/desktop-widget.cpp:1346
#12 0x0000000000462d04 in sp_file_new (templ=<value optimized out>)
at ../../src/file.cpp:129
#13 0x000000000046303e in sp_file_new_default () at ../../src/file.cpp:177
#14 0x0000000000454167 in sp_main_gui (argc=1, argv=0x7fffffffe328)
at ../../src/main.cpp:949
#15 0x0000000000453689 in main (argc=1, argv=<value optimized out>)
at ../../src/main.cpp:689
Regards, Krzysztof
5:06 a.m.
On Jan 10, 2010, at 8:03 AM, bulia byak wrote:
Jon,
Thanks for your work on toolbars. It will be nice to have the ability
to make them vertical. However:
- PLEASE describe your changes in Release Notes
Why, yes. Of course.
However, since all this work is in major flux now, it's hard to actually describe what
will be there tomorrow.
- I think it would be even more useful to have the ability to put
two
or more toolbars on the same horizontal or vertical strip, next to
each other. Will your refactoring allow for that?
Two in the same strip may not be in the first passes. However, being able to arbitrarily
define your own might... and thus might function in a similar way.
- I assume the now-vertical snapping toolbar is more of a
demonstration - I really don't see much reason to single it out for
vertical placement?
Well, it was partially to get the orientation change working. But more importantly it does
solve a major problem for many people. Those with wide screens, and especially those on
netbooks, lost a lot of usable space with the snap toolbar added. One of the more common
requests was to place it on the right. And aside from screen aspect, it even helps when
one is working on portrait aspect documents.
- Still, I couldn't re-attach the snapping toolbar into a
horizontal
position anywhere. It's either its original vertical position at the
right, or floating. And re-attaching it to the original position is
also quite difficult - the magnetic zone is very small. Can you affect
this or is this unfixable in GTK?
This might be an issue with GTK. Our code has been setting the attach edge to
"left" no matter where it was. I've done a few experiments on this, with no
significant improvements. There is a final one that can be done that might keep the
snapped edge from going too thin. I might be able to check that next week.
- Will you be able to block standalone floating state for toolbars?
As
discussed many times, they sink under the main window which makes them
unusable.
We should look at this issue in detail. I've not seen it happen myself, so it's
not a universal problem. We probably don't want to break functionality for those who
use it.
2:13 a.m.
On Sun, Jan 10, 2010 at 4:06 PM, Jon Cruz <jon@...18...> wrote:
> - I think it would be even more useful to have the ability to put
two
> or more toolbars on the same horizontal or vertical strip, next to
> each other. Will your refactoring allow for that?
Two in the same strip may not be in the first passes. However, being able to arbitrarily
define your own might... and thus might function in a similar way.
But that would be major pain to have to define anything for the same
thing that in Xara is done by drag and drop...
> - Will you be able to block standalone floating state for
toolbars? As
> discussed many times, they sink under the main window which makes them
> unusable.
We should look at this issue in detail. I've not seen it happen myself, so it's
not a universal problem. We probably don't want to break functionality for those who
use it.
It sinks at least on latest KDE in Ubuntu 9.10 and on Windows, so it's
a very large problem even if not universal.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
2:20 a.m.
On Jan 11, 2010, at 9:13 AM, bulia byak wrote:
On Sun, Jan 10, 2010 at 4:06 PM, Jon Cruz <jon@...18...>
wrote:
>> - I think it would be even more useful to have the ability to put two
>> or more toolbars on the same horizontal or vertical strip, next to
>> each other. Will your refactoring allow for that?
>
> Two in the same strip may not be in the first passes. However, being able to
arbitrarily define your own might... and thus might function in a similar way.
But that would be major pain to have to define anything for the same
thing that in Xara is done by drag and drop...
Drag and drop might be used here too.
>> - Will you be able to block standalone floating state for
toolbars? As
>> discussed many times, they sink under the main window which makes them
>> unusable.
>
> We should look at this issue in detail. I've not seen it happen myself, so
it's not a universal problem. We probably don't want to break functionality for
those who use it.
It sinks at least on latest KDE in Ubuntu 9.10 and on Windows, so it's
a very large problem even if not universal.
I was just reading about this. It appears that though they don't acknowledge ignoring
things everyone else handles as being a bug, they seem to be changing it now.
However, "adapting" to the window manager being used is well within this scope.
4:49 a.m.
On Montag 11 Januar 2010, bulia byak wrote:
On Sun, Jan 10, 2010 at 4:06 PM, Jon Cruz <jon@...18...>
wrote:
> We should look at this issue in detail. I've not seen it happen myself,
> so it's not a universal problem. We probably don't want to break
> functionality for those who use it.
It sinks at least on latest KDE in Ubuntu 9.10 and on Windows, so it's
a very large problem even if not universal.
Strange. KDE/Qt certainly has had floating toolbars staying on top of their
respective windows for years. Maybe setting some proper X11 properties would
help? I would expect stuff like this to be in the NetWM spec.
--
Ciao, / / .o.
/--/ ..o
/ / ANS ooo
7:41 a.m.
On Mon, Jan 11, 2010 at 3:49 PM, Hans Meine <hans_meine@...240...> wrote:
Strange. KDE/Qt certainly has had floating toolbars staying on top
of their
respective windows for years. Maybe setting some proper X11 properties would
help? I would expect stuff like this to be in the NetWM spec.
Maybe in some other programs but not in Inkscape, try for yourself.
We're not using any hacks, just standard GTK toolbars.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
12:18 p.m.
On Jan 11, 2010, at 11:49 AM, Hans Meine wrote:
Strange. KDE/Qt certainly has had floating toolbars staying on top of their
respective windows for years. Maybe setting some proper X11 properties would
help? I would expect stuff like this to be in the NetWM spec.
The general gist of the problem (or at least one problem with "floaters") is
that there are some proper X11 properties that are in the NetWM specs, but the spec does
not dictate exactly what a window manager should do when implementing them.
In the past, the argument seemed to come down to the KDE folks saying it wasn't a bug
since the specs never said they *couldn't* ignore the props, even if all the other
window managers treated them in a certain way.
I'd be interested if you see KDE behaving correctly in regards to floating toolbars
for programs that are not KDE-based. The initial thrust of the KDE approach has been
"use our classes to get so-and-such". So I'd not be surprised to see KDE
programs behave well, but non-KDE have some issues.
9:56 p.m.
Hi again!
Am Dienstag, 12. Januar 2010 04:18:13 schrieben Sie:
I'd be interested if you see KDE behaving correctly in regards to
floating
toolbars for programs that are not KDE-based. The initial thrust of the
KDE approach has been "use our classes to get so-and-such". So I'd not be
surprised to see KDE programs behave well, but non-KDE have some issues.
Sorry, but this sounds like general bashing of "KDE folks". I will try to
ignore it.
To get back to the topic: I had a quick look at the properties of inkscapes
toolbars, and obviously WM_TRANSIENT_FOR is missing. That does not even
belong to NetWM, but is a standard Inter-Client Communication Conventions
property. Obviously, there have been requests to add support for it to gtk as
early as 1998:
http://mail.gnome.org/archives/gtk-list/1998-November/msg00581.html
I don't know the GTK developer's view on this at all, but I verified that this
is the very property which is used by KDE applications for making toolbars
stay on top of their respective main windows. Nothing KDE-specific here
AFAICS.
HTH,
Hans
10:04 p.m.
New subject: toolbars - nearly solved
Am Freitag, 15. Januar 2010 13:56:39 schrieb Hans Meine:
To get back to the topic: I had a quick look at the properties of
inkscapes toolbars, and obviously WM_TRANSIENT_FOR is missing. [...]
Someone who has GTK/Inkscape source lying around should check whether
gtk_window_set_transient_for() is in the code path for inkscapes toolbar
creation:
http://developer.gimp.org/api/2.0/gtk/GtkWindow.html#gtk-window-set-trans...
Ciao,
Hans
12:31 a.m.
New subject: toolbars - nearly solved
On Fri, Jan 15, 2010 at 9:04 AM, Hans Meine <hans_meine@...240...> wrote:
Am Freitag, 15. Januar 2010 13:56:39 schrieb Hans Meine:
> To get back to the topic: I had a quick look at the properties of
> inkscapes toolbars, and obviously WM_TRANSIENT_FOR is missing. [...]
This is indeed one of the worst holes in GTK, which I've been
struggling with for years. For the dialogs we create, we set this flag
manually, but for tear-off toolbars there's no way to do even that.
GTK should be shamed again and again for this until they fix it.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
5:24 a.m.
New subject: toolbars - nearly solved
2010/1/15 bulia byak <buliabyak@...400...>:
This is indeed one of the worst holes in GTK, which I've been
struggling with for years. For the dialogs we create, we set this flag
manually, but for tear-off toolbars there's no way to do even that.
GTK should be shamed again and again for this until they fix it.
A more effective approach is to submit a bug report with a patch and
then post on their list or spam the maintainers directly until someone
applies it. That's how I finally fixed the accumulator problem in
libsigc++.
Regards, Krzysztof
10:19 p.m.
New subject: toolbars - nearly solved
On Friday 15 January 2010 21:24:12 Krzysztof Kosiński wrote:
2010/1/15 bulia byak <buliabyak@...400...>:
> This is indeed one of the worst holes in GTK, which I've been
> struggling with for years. For the dialogs we create, we set this flag
> manually, but for tear-off toolbars there's no way to do even that.
> GTK should be shamed again and again for this until they fix it.
A more effective approach is to submit a bug report with a patch and
then post on their list or spam the maintainers directly until someone
applies it. That's how I finally fixed the accumulator problem in
libsigc++.
For "the accumulator problem", I /might/ have been motivated to write a patch
(luckily they always worked for me though ;-p), while I am sure that other
people (who have seen more than zero lines of GTK's source) will be more
qualified for this and be much faster with it.
If someone happens to know how Gnome (or whatever window manager you're
successfully using) recognizes the mainwindow of Inkscape's floating toolbars,
it might even be faster (not the best way though, if you ask me) to add
similar support to kwin. See the attached reply of Lubos, who is not
subscribed here.
Have a nice day,
Hans
7:01 p.m.
On Jan 10, 2010, at 8:03 AM, bulia byak wrote:
- Will you be able to block standalone floating state for toolbars?
As
discussed many times, they sink under the main window which makes them
unusable.
First cut of that blockage is in. Should prevent things on MS Windows, or when running
inside of KWin as the window manager.
We can probably provide some refinements, including prefs to override, in a bit.
4816
days inactive
4825
days old
inkscape-devel@lists.inkscape.org
13 comments
4 participants
participants (4)
-
bulia byak -
Hans Meine -
Jon Cruz -
Krzysztof Kosiński