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.
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
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.
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.
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.
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.
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.
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.
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
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-transien...
Ciao, Hans
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.
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
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
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.
participants (4)
-
bulia byak -
Hans Meine -
Jon Cruz -
Krzysztof Kosiński