Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked
Are you saying that at some stage there was suport for native windows file dialogs which was then removed? If so why was this? and if I was to add the support in once again would I be reversing some community decision from a while ago? if that decision was made, on what grounds was it made?
----- Original Message ----- From: "Bob Jamison" <rwjj@...127...> To: "Joel Holdsworth" <joel@...1709...>; inkscape-devel@lists.sourceforge.net Sent: Tuesday, June 26, 2007 4:20 PM Subject: SPAM-LOW: Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked
Joel Holdsworth wrote:
Hi again, I'm currently working on a patch to add support for native file dialogs for windows users. It's worked out pretty well, and I'm almost finished. I have one slight problem though: parent windows. In the GTK version, sp_file_open_dialog (in file.cpp) is called from inside FileVerb::Perform in verbs.cpp. But how is it possible to get the GdkWindow object of the windows in which the verb was invoked? If I have this I can add it as an extra parameter to sp_file_open_dialog, to enable both the GTK, and Win32 file dialogs to be correctly set as child windows of the document's window. Any suggestions? Joel Holdsworth
You might look at src/dialogs/filedialog-win32.cpp as an example. It was the original native dialog that we replaced with the current one.
bob
Joel Holdsworth wrote:
Are you saying that at some stage there was suport for native windows file dialogs which was then removed? If so why was this? and if I was to add the support in once again would I be reversing some community decision from a while ago? if that decision was made, on what grounds was it made?
Yes, almost 3 years ago, we had a lot of talks about this, and the general consensus was to move to the new GtkFileChooser for consistency, for the bookmarks, and for the nifty Preview.
This was part of the work to make win32 not be perceived as a second-class port of the code, but rather another supported build.
Maybe having a preferences.xml option to show the old dialog as an option would be good. Or maybe a control on each dialog that would switch to the alternate view. But it would NOT be a good idea to disable the GtkFileChooser for all win32 users. Far, far too much work has gone into it to throw it away.
bob
On 6/26/07, Bob Jamison wrote:
Yes, almost 3 years ago, we had a lot of talks about this, and the general consensus was to move to the new GtkFileChooser for consistency, for the bookmarks, and for the nifty Preview.
This was part of the work to make win32 not be perceived as a second-class port of the code, but rather another supported build.
Maybe having a preferences.xml option to show the old dialog as an option would be good. Or maybe a control on each dialog that would switch to the alternate view. But it would NOT be a good idea to disable the GtkFileChooser for all win32 users. Far, far too much work has gone into it to throw it away.
As someone who is talking to users on regular basis I can tell you that Gtk open/save dialog is mostly hated by Windows users, at least here. I don't mind this being an option, but I would provide native open/save dialogs on both Windows and Mac (if possible) by default, since application is supposed to blend into environment and native dialogs are expected.
Alexandre
Alexandre Prokoudine wrote:
As someone who is talking to users on regular basis I can tell you that Gtk open/save dialog is mostly hated by Windows users, at least here.
Dang I hate those stupid open windows in Inkscape - I would personally be happy to have the option to use the Windows dialogs! With previews, of course ;)
Gail
On Tue, 26 Jun 2007 13:01:49 -0400, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
Dang I hate those stupid open windows in Inkscape - I would personally be happy to have the option to use the Windows dialogs! With previews, of course ;)
While I'm not a frequent user of Inkscape on Windows, I've had to do so occasionally for work; I think I'd also prefer a native file dialog (though I'd miss the Gtk dialog's bookmarks a little bit).
Previews are another issue, though -- before we could implement them in the native dialog, we'd need to determine how to embed a Gtk widget in a Win32 window. If we can get that part sorted out, then the usual dialog customization approach should work:
http://msdn2.microsoft.com/en-us/library/ms646960.aspx#_win32_Explorer_Style...
(Win32 programming is one of the few things that makes me miss working with Gtk...)
-mental
MenTaLguY wrote:
Previews are another issue, though -- before we could implement them in the native dialog, we'd need to determine how to embed a Gtk widget in a Win32 window.
This is probably a naive question, but if the files are just SVG, it seems that the native Windows preview mechanism would be able to display them. But I could be wrong :)
Gail
On Tue, 26 Jun 2007 13:50:21 -0400, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
This is probably a naive question, but if the files are just SVG, it seems that the native Windows preview mechanism would be able to display them. But I could be wrong :)
There's a native Windows preview mechanism?
-mental
On Tue, 26 Jun 2007 14:11:15 -0400, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
I was thinking pretty much what Joel was talking about in a subsequent email.
Ahh, yeah. IPreviewHandler.
All these new-fangled Vista things... :)
-mental
Am Dienstag, den 26.06.2007, 13:50 -0400 schrieb Gail Banaszkiewicz:
MenTaLguY wrote:
Previews are another issue, though -- before we could implement them in the native dialog, we'd need to determine how to embed a Gtk widget in a Win32 window.
This is probably a naive question, but if the files are just SVG, it seems that the native Windows preview mechanism would be able to display them. But I could be wrong :)
No, there is no SVG-Preview in Windows.
Tobias
On Tue, 26 Jun 2007 20:34:55 +0200, Tobias Jakobs <tobias.jakobs@...128...> wrote:
This is probably a naive question, but if the files are just SVG, it seems that the native Windows preview mechanism would be able to display them. But I could be wrong :)
No, there is no SVG-Preview in Windows.
I think what she and Joel are getting at is that on Vista (and XP?), it should be possible for us to provide it.
-mental
MenTaLguY wrote:
On Tue, 26 Jun 2007 20:34:55 +0200, Tobias Jakobs <tobias.jakobs@...128...> wrote:
This is probably a naive question, but if the files are just SVG, it seems that the native Windows preview mechanism would be able to display them. But I could be wrong :)
No, there is no SVG-Preview in Windows.
I think what she and Joel are getting at is that on Vista (and XP?), it should be possible for us to provide it.
-mental
Is it really necessary for the Preview to be a GtkWindow? IMHO, someone could merely add a standard win32 CreateWindow() to a native dialog, buffer the preview to a bitmap, and draw the image on the window.
But adding SVG thumbnail capability to File Explorer would be fine, too. Maybe some code from Nautilus could be borrowed for that.
Either one would be enough to convince me. But they would need to be done first, not eventually (meaning "never").
bob
like it would be enough to convince me, too
Bob Jamison wrote:
Is it really necessary for the Preview to be a GtkWindow? IMHO, someone could merely add a standard win32 CreateWindow() to a native dialog, buffer the preview to a bitmap, and draw the image on the window.
I found this info: https://msdn2.microsoft.com/en-us/library/ms646951.aspx
bob
Ok fair enough. As you can probably tell, I'm only just getting involved so I'm oblivious to these earlier discussions. You'll have to excuse my bullishness.
I've been using Inkscape heavily for about a year now, and it's been really great seeing it grow an develop. One thing I notice quite regularly is that because this a GTK app, it is inevitably primarily designed for Gnome. An example of this problem is the edit box I-beam cursor. In 0.45.1 when you hover over an edit box in windows you get a GTK style I-beam, rather than the windows system I-beam. I'm very glad that this has now been fixed in the developement builds. A second example is scrollbars. When you scroll to the maximum or minimum extent, the arrow buttons grey out. That behaviour makes sense, but it's not Windows standard, so it sticks out like a sore thumb.
I guess I got a similar impression of the file dialogs. Far from making me feel like a first class citizen, it made me feel like it was one of those linuxy things that noone had got round to fixing sorting out yet - Linux being the primary platform for the project, and I being a mere "M$ Windoze" user. I definitely don't think we should add more options to resolve this - as they tend to be an excuse for dodging hard design decisions. I agree that it would be a shame to loose bookmarks and preview, but then I don't think many Windows users will know what they're missing. Instead they'll be happy that the application has the humility to "play the Windows game the Windows way".
I think it's quite important that we try and show Windows users that we take their platform sersously, because the majority of developers work on that platform, so we could do with attracting their input to get more inovation, and faster progress.
----- Original Message ----- From: "Bob Jamison" <rwjj@...127...> To: "Joel Holdsworth" <joel@...1709...>; inkscape-devel@lists.sourceforge.net Sent: Tuesday, June 26, 2007 5:46 PM Subject: SPAM-LOW: Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked
Joel Holdsworth wrote:
Are you saying that at some stage there was suport for native windows file dialogs which was then removed? If so why was this? and if I was to add the support in once again would I be reversing some community decision from a while ago? if that decision was made, on what grounds was it made?
Yes, almost 3 years ago, we had a lot of talks about this, and the general consensus was to move to the new GtkFileChooser for consistency, for the bookmarks, and for the nifty Preview.
This was part of the work to make win32 not be perceived as a second-class port of the code, but rather another supported build.
Maybe having a preferences.xml option to show the old dialog as an option would be good. Or maybe a control on each dialog that would switch to the alternate view. But it would NOT be a good idea to disable the GtkFileChooser for all win32 users. Far, far too much work has gone into it to throw it away.
bob
On 6/26/07, Joel Holdsworth <joel@...1709...> wrote:
as they tend to be an excuse for dodging hard design decisions. I agree that it would be a shame to loose bookmarks and preview, but then I don't think many Windows users will know what they're missing.
By the way, in 0.46 they will also be missing some conveniences I recently added:
* The list of folder shortcuts in the Open dialog includes the folder with Inkscape's SVG examples for easy access. Similarly, the Save dialog has a shortcut for the user's own templates dialog making it easy to save the current document as a template (if saved as default.svg, it will be loaded every time you run Inkscape or create new document with Ctrl+N; with any other name, it will be added to the File > New submenu).
We're getting a lot of user questions on how to save templates, and it was a pain to direct them to go to the crazily convoluted and platform-specific filepaths for that simple operation. So I added this bookmark which solves the problem simply and nonobtrusively. Too bad it's not going to work on Windows with native filedialogs.
Easy access to the examples folder is also a very important selling point, especially for newbies. As it is now, I'm sure many users don't even suspect that we have such a folder.
On Tue, 26 Jun 2007 15:26:24 -0300, "bulia byak" <buliabyak@...400...> wrote:
Easy access to the examples folder is also a very important selling point, especially for newbies. As it is now, I'm sure many users don't even suspect that we have such a folder.
It is possible in principle to customize the Win32 places bar, though there's still the question of whether it's worth the effort:
http://msdn.microsoft.com/msdnmag/issues/03/03/CuttingEdge/
-mental
Am Dienstag, den 26.06.2007, 18:09 +0100 schrieb Joel Holdsworth:
One thing I notice quite regularly is that because this a GTK app, it is inevitably primarily designed for Gnome. An example of this problem is the edit box I-beam cursor. In 0.45.1 when you hover over an edit box in windows you get a GTK style I-beam, rather than the windows system I-beam. I'm very glad that this has now been fixed in the developement builds. A second example is scrollbars. When you scroll to the maximum or minimum extent, the arrow buttons grey out. That behaviour makes sense, but it's not Windows standard, so it sticks out like a sore thumb.
If you have problems like this, please fix it in GTK and not in every GTK app. GTK+ is a multi-platform toolkit by the definition on there website and not only an Linux toolkit that works on windows too.
I guess I got a similar impression of the file dialogs. Far from making me feel like a first class citizen, it made me feel like it was one of those linuxy things that noone had got round to fixing sorting out yet - Linux being the primary platform for the project, and I being a mere "M$ Windoze" user. I definitely don't think we should add more options to resolve this - as they tend to be an excuse for dodging hard design decisions. I agree that it would be a shame to loose bookmarks and preview, but then I don't think many Windows users will know what they're missing. Instead they'll be happy that the application has the humility to "play the Windows game the Windows way".
I agree with you that we need other file dialogs on windows. An old usability rule is: "The Platform is the King." That means, it's not important to have the same dialogs on every platform, but to fit into the platform as good as possible. So the first question is, is there a standard Windows file open dialog? Look at Word, Photoshop, Coral Draw, Notepad and you will find 4 different file open dialogs. So we don't need "the standard windows file open dialog" because the users are used to different file dialogs. But we need a file dialog that fits better into windows. So I would suggest to write a gtk dialog, that looks like a windows dialog. The pros are, that all windows gtk apps will benefit from it and that we can still use the preview and the bookmarks.
I think it's quite important that we try and show Windows users that we take their platform sersously, because the majority of developers work on that platform, so we could do with attracting their input to get more inovation, and faster progress.
I can only agree with you, that Windows is an very important platform. But please don't hack the Windows support into Inkscape but make it the "right way". ;)
Regards, Tobias
I'm personnelly for keeping the current gtk dialog, i use both windows and linux and I simply expect inkscape to provide the same functionality and work in the same way (where possible) on both platforms. This provides maximum usability for multi-platform users and reduces the need to know the platform specifics when helping other users. I'm not against making things more "usable" for windows users, so i feel that IF need that a gtk dialog made to look like office 2003 open dialog ( what tobias suggested) is probably the best half way point. It offers bookmarking and previews. It still wouldn't function and work in exactly the same way but at least it would still be there.
Joshua L. Blocher verbalshadow
On Tue, 26 Jun 2007 21:08:10 +0200, Tobias Jakobs <tobias.jakobs@...128...> wrote:
So the first question is, is there a standard Windows file open dialog? Look at Word, Photoshop, Coral Draw, Notepad and you will find 4 different file open dialogs.
They are all customizations of the same standard dialog.
So we don't need "the standard windows file open dialog" because the users are used to different file dialogs. But we need a file dialog that fits better into windows. So I would suggest to write a gtk dialog, that looks like a windows dialog.
The standard windows dialog is highly integrated with the Windows shell (Explorer), so replacing it entirely in Gtk is an extremely large project and the result would be inconsistent across different Windows versions.
-mental
On 6/26/07, Joel Holdsworth <joel@...1709...> wrote:
Are you saying that at some stage there was suport for native windows file dialogs which was then removed? If so why was this? and if I was to add the support in once again would I be reversing some community decision from a while ago? if that decision was made, on what grounds was it made?
The old native dialogs were dropped simply because no one could maintain them. We didn't have as many developers back then and almost no Windows developers. So, to succeed this time, it is kinda required that you not only make the patch but also maintain it for at least some time, fixing bugs and regressions etc. Also, in any case, I think we need to build a consensus first among Windows users and developers on whether this change is indeed desirable (considering the lack of preview and bookmarks).
I think we need to build a consensus first among Windows users and developers on whether this change is indeed desirable (considering the lack of preview and bookmarks).
Sure.
So, to succeed this time, it is kinda required that you not only make the patch but also maintain it for at least some time, fixing bugs and regressions etc.
That seems reasonable. I havn't been on the developers list long, but I think I'll be here for quite a while. I have a significant vested interest in Inkscape being a high quality app, given that I've mostly migrated away from CorelDRAW now.
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "Joel Holdsworth" <joel@...1709...> Cc: inkscape-devel@lists.sourceforge.net Sent: Tuesday, June 26, 2007 5:48 PM Subject: Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked
On 6/26/07, Joel Holdsworth <joel@...1709...> wrote:
Are you saying that at some stage there was suport for native windows file dialogs which was then removed? If so why was this? and if I was to add the support in once again would I be reversing some community decision from a while ago? if that decision was made, on what grounds was it made?
The old native dialogs were dropped simply because no one could maintain them. We didn't have as many developers back then and almost no Windows developers. So, to succeed this time, it is kinda required that you not only make the patch but also maintain it for at least some time, fixing bugs and regressions etc. Also, in any case, I think we need to build a consensus first among Windows users and developers on whether this change is indeed desirable (considering the lack of preview and bookmarks).
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
participants (8)
-
Alexandre Prokoudine -
Bob Jamison -
bulia byak -
Gail Banaszkiewicz -
Joel Holdsworth -
Joshua Blocher -
MenTaLguY -
Tobias Jakobs