Inkscape / win32 with gtk2.10
Hi, all.
Starting with Bulia's need for me to make an Inkscape build with Tor's patch for transient dialogs on win32, there was a need for me to change the build to use gtk2.10. Since I was going to change the build, I thought it would be good to modernize it, thus the Buildtool. Whew. Well, I got the Buildtool working yesterday, and I just now got a gtk2.10 build working. Tor's patch tomorrow?
This copy was made with gtk2.10: http://inkscape.modevia.com/win32/Inkscape0611161701.7z
This is not just a dll drop-in replacement, but a complete build with new libraries. It seems to work ok here, but people might want to give it a try to see if it works for them.
bob
On 11/16/06, Bob Jamison <rwjj@...127...> wrote:
This copy was made with gtk2.10: http://inkscape.modevia.com/win32/Inkscape0611161701.7z
This archive lacks three necessary dlls: intl.dll, xmlparse.dll, libpng13.dll. I had to copy them from another Inkscape installation to make it work.
bulia byak wrote:
On 11/16/06, Bob Jamison <rwjj@...127...> wrote:
This copy was made with gtk2.10: http://inkscape.modevia.com/win32/Inkscape0611161701.7z
This archive lacks three necessary dlls: intl.dll, xmlparse.dll, libpng13.dll. I had to copy them from another Inkscape installation to make it work.
Ok, I made another upload with this fix: http://inkscape.modevia.com/win32/Inkscape0611161834.7z
Here is the new lib bundle: http://inkscape.modevia.com/win32libs/gtk210-061116.7z
bob
Speaking of new Gtk, what's the word on removing the text entry we hacked into the file dialog? Newest Gtk appears to have its own text entry again, and ours breaks it. I'd like to have that resolved for the release too.
-mental
On 11/16/06, MenTaLguY <mental@...3...> wrote:
Speaking of new Gtk, what's the word on removing the text entry we hacked into the file dialog? Newest Gtk appears to have its own text entry again, and ours breaks it. I'd like to have that resolved for the release too.
Agreed, that must be fixed. Users of pre-2.10 can either upgrade or live with Ctrl+L for a while.
bulia byak wrote:
On 11/16/06, MenTaLguY <mental@...3...> wrote:
Speaking of new Gtk, what's the word on removing the text entry we hacked into the file dialog? Newest Gtk appears to have its own text entry again, and ours breaks it. I'd like to have that resolved for the release too.
Agreed, that must be fixed. Users of pre-2.10 can either upgrade or live with Ctrl+L for a while.
Done. Notice that with FileChooser evolving and our hacks becoming unnecessary, the basic dialog code is becoming trivial. All of the work is with the previews and the filters.
One thing I noticed: earlier I hit ^L to get the real location field to appear, but it is now visible always. Was this my imagination, or does this get saved in the cache along with the shortcuts?
On the SaveAs side, I think the hack to force-expand the file directory tree is still necessary.
Typeahead doesn't seem to be working yet.
bob
Here is a build with the Gdk transient dialog patched DLL and just for fun, Cairo 1.3.2.
http://inkscape.modevia.com/win32/Inkscape0611181504.7z
bob
Bob Jamison wrote:
Here is a build with the Gdk transient dialog patched DLL and just for fun, Cairo 1.3.2.
The transient dialog patch has been such a long time coming, does anyone recall the details of the original problem? The details of the changes the patch made? The identity of the original patch author? What changes need to be made to Inkscape?
It would be really nice if we could put our keyboards together and get this thing sorted out.
Aaron Spike
--- Aaron Spike <aaron@...749...> wrote:
Bob Jamison wrote:
Here is a build with the Gdk transient dialog patched DLL and just for fun, Cairo 1.3.2.
The transient dialog patch has been such a long time coming, does anyone recall the details of the original problem? The details of the changes the patch made? The identity of the original patch author? What changes need to be made to Inkscape?
It would be really nice if we could put our keyboards together and get this thing sorted out.
Aaron Spike
Problem is that dialogs dont stay on top on windows. Running this build on XP they still dont stay on top when you click in teh main window and give it focus. Not sure if changes are needed to what inkscape is doing wrt this. Would definitely be a good bug to be able to close.
Cheers
John
____________________________________________________________________________________ Sponsored Link
$420k for $1,399/mo. Think You Pay Too Much For Your Mortgage? Find Out! www.LowerMyBills.com/lre
Had a dig through the code to see if i could get this working yesterday, took the ifdefs out of dialog.cpp and desktop-widget.cpp, and it kind of works. dialogs stay on top during drawing etc, and when you switch tools, however dont get minimised with the main window. In testing I've also got the main window to freak out slightly so that it stays always on top, seems to be picking up the attribute the dialogs are supposed to be having, I havent been able to work out how to reliably reproduce this tho. The code to do with the whole transient thing seems to have moved about a bit from when the gtk patch was originally written, it has been an awful long time, and some of the desktop stuffs been C++ ified i think. Bit out of my depth with trying to work out whats doing what, but if anyones got any suggestions I'm happy to try stuff out.
Cheers
John
--- John Cliff <simarilius@...36...> wrote:
--- Aaron Spike <aaron@...749...> wrote:
Bob Jamison wrote:
Here is a build with the Gdk transient dialog patched DLL and just for fun, Cairo 1.3.2.
The transient dialog patch has been such a long time coming, does anyone recall the details of the original problem? The details of the changes the patch made? The identity of the original patch author? What changes need to be made to Inkscape?
It would be really nice if we could put our keyboards together and get this thing sorted out.
Aaron Spike
Problem is that dialogs dont stay on top on windows. Running this build on XP they still dont stay on top when you click in teh main window and give it focus. Not sure if changes are needed to what inkscape is doing wrt this. Would definitely be a good bug to be able to close.
Cheers
John
____________________________________________________________________________________
Sponsored Link
$420k for $1,399/mo. Think You Pay Too Much For Your Mortgage? Find Out! www.LowerMyBills.com/lre
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
On 11/25/06, John Cliff <simarilius@...36...> wrote:
Had a dig through the code to see if i could get this working yesterday, took the ifdefs out of dialog.cpp and desktop-widget.cpp, and it kind of works. dialogs stay on top during drawing etc, and when you switch tools, however dont get minimised with the main window. In testing I've also got the main window to freak out slightly so that it stays always on top, seems to be picking up the attribute the dialogs are supposed to be having, I havent been able to work out how to reliably reproduce this tho.
I got roughly the same results, and like you couldn't get much further than that. John, what is needed is to secure support from Tor, the patch author, and the GTK guys, and to get this, we need something different altogether: we need a simple test application. They are not interested in tracing the huge Inkscape codebase, and this is understandable. So we just need to take some simple window example from GTK distribution and make it spawn a dialog and make it transient, and then test it extensively on windows (and linux too, there are bugs there as well!) with regard to:
- transient always on top of its parent, but not other windows
- transient minimized and restored with parent
- transient can be hidden from taskbar with no harmful side effects
- no other bugs
If you see any problems, send that simple test app to Tor and the original patch author to investigate. That's the only way we can count on getting help from them.
After that is fixed, we can move on to the more complex scenario that is actually used by Inkscape: two or more main windows belonging to the same application, and a dialog which switches its transiency parent when you switch focus between these main windows, so it's always on top of the topmost main window. But, like I said, let's make sure the simple scenario works flawlessly first.
participants (5)
-
Aaron Spike -
Bob Jamison -
bulia byak -
John Cliff -
MenTaLguY