Hi Guys,
So I have been doing a lot of work on the Gallery dialog (the OCAL dialog is still in progress ;] ) and I have finished!
Again I was wondering whether I could get some testing, especially on some different platforms. You will find the dialog in File > Gallery
Thanks!
Diff on trunk: https://code.launchpad.net/~and471/inkscape/gallery/+merge/58442/+preview-di...
Branch: bzr branch lp:~and471/inkscape/gallery
Screencast: http://www.youtube.com/watch?v=PKMxkk_pobA
Blueprint: https://blueprints.launchpad.net/inkscape/+spec/gallery
2011/4/20 Andrew <rugby471@...400...>:
Hi Guys,
So I have been doing a lot of work on the Gallery dialog (the OCAL dialog is still in progress ;] ) and I have finished!
Again I was wondering whether I could get some testing, especially on some different platforms. You will find the dialog in File > Gallery
I wanted to code something exactly like this for some time, to simplify working with icon themes, which often have common elements. Awesome! Regards, Krzysztof
On Wed, 2011-04-20 at 07:57 +0100, Andrew wrote:
So I have been doing a lot of work on the Gallery dialog (the OCAL dialog is still in progress ;] ) and I have finished!
Again I was wondering whether I could get some testing, especially on some different platforms. You will find the dialog in File > Gallery
Sounds like what I've been doing for quite a while:
Thanks for the functionality :-) looks awesome.
Now we need a way to drag groups back to your dialog to create svgs instantly. :-D
Martin,
On 20/04/11 17:05, Martin Owens wrote:
On Wed, 2011-04-20 at 07:57 +0100, Andrew wrote:
So I have been doing a lot of work on the Gallery dialog (the OCAL dialog is still in progress ;] ) and I have finished!
Again I was wondering whether I could get some testing, especially on some different platforms. You will find the dialog in File > Gallery
Sounds like what I've been doing for quite a while:
Thanks for the functionality :-) looks awesome.
Now we need a way to drag groups back to your dialog to create svgs instantly. :-D
Martin,
Thanks for the kind words everyone :)
One thing also, do you feel any extra controls should be added to the dialog? For example I think I am going to add a refresh button.
On Wed, 2011-04-20 at 18:40 +0100, Andrew wrote:
One thing also, do you feel any extra controls should be added to the dialog? For example I think I am going to add a refresh button.
Don't add a refresh button, tie the code into inotify so you can get a signal when files change in the directory. Should be fairly simple and anything to reduce the complexity of the design the user is a positive.
Have an option to show previews only, large previews (icon view?) as well as a list view list like you have in the video shown.
You might also want to specify the file size in some way. Maybe a colour coding or some other visual queue.
Martin,
Very good. I shall find that useful in icon design. Thanks for making it!
One thing that I think would be *nice* but fairly complex is to have an SVG view there rather than a list view (as an option, I mean, still keeping this way you have just created as well). Have an SVG file which contains elements (generally groups) which you can just drag across into place; then the user could arrange them as they want it, manage display of different size things, put in labels helpful to them, and generally customise it to their heart's content.
Aside: a further extension of that which I would like (but don't expect to get any time soon!) is for it to be able to copy styles - select object/s in the main region and, right clicking on an object in the gallery, "apply styles" and it gets the border, fill, filters, etc.
-- Chris
On Apr 20, 2011, at 11:54 AM, Martin Owens wrote:
On Wed, 2011-04-20 at 18:40 +0100, Andrew wrote:
One thing also, do you feel any extra controls should be added to the dialog? For example I think I am going to add a refresh button.
Don't add a refresh button, tie the code into inotify so you can get a signal when files change in the directory. Should be fairly simple and anything to reduce the complexity of the design the user is a positive.
There are some significant problems with inotify, so I'd recommend avoid it if possible.
There are other ways to implement refresh without resorting to a button, so we should look at those.
It may or may not be helpful to have you code call into the new "resource/asset manager" I'm coding up now.
On Wed, Apr 20, 2011 at 8:03 PM, Jon Cruz <jon@...18...> wrote:
It may or may not be helpful to have you code call into the new "resource/asset manager" I'm coding up now.
Any chance you would be willing to push this work into a public repo if it's not "production-friendly" currently? That way Andrew could look into how it might be used?
Cheers, Josh
On Apr 20, 2011, at 9:42 PM, Josh Andler wrote:
On Wed, Apr 20, 2011 at 8:03 PM, Jon Cruz <jon@...18...> wrote:
It may or may not be helpful to have you code call into the new "resource/asset manager" I'm coding up now.
Any chance you would be willing to push this work into a public repo if it's not "production-friendly" currently? That way Andrew could look into how it might be used?
I was expecting to get it in trunk either tonight or tomorrow night.
Naming can be the trickiest part.
So... :)
Don't add a refresh button, tie the code into inotify so you can get a signal when files change in the directory. Should be fairly simple and anything to reduce the complexity of the design the user is a positive.
There are some significant problems with inotify, so I'd recommend
avoid it if
possible.
I really like Martin's idea, that the directory should automatically update when a file is added/removed.
How about Glib::FileMonitor? I haven't used it before, but I just came across it and it looks the part, should work on other platforms as well, rather than inotify which is restricted to Linux.
Have an option to show previews only, large previews (icon view?) as well as a list view list like you have in the video shown.
This should be quite easy to do, as Gtk::TreeView and Gtk::IconView use the same data store.
You might also want to specify the file size in some way. Maybe a colour coding or some other visual queue.
I don't know about this one. I think it would add too much visual clutter for not a lot of gain, besides I think a user would know whether a file was very large or not.
One thing that I think would be nice but fairly complex is to have an
SVG view there
rather than a list view (as an option, I mean, still keeping this way
you have just >created
as well). Have an SVG file which contains elements (generally groups)
which you can
just drag across into place; then the user could arrange them as they
want it, manage
display of different size things, put in labels helpful to them, and
generally customise > it to their heart's content.
Aside: a further extension of that which I would like (but don't
expect to get any time > soon!) is for it to be able to copy styles - select object/s in the main region and, right > clicking on an object in the gallery, "apply styles" and it gets the border, fill, filters, etc.
Hehe I think this would be possible, but it wouldn't be something I could do, but good idea none-the-less :) Maybe someone else could take this up in the future :)
So thanks for all the feedback guys and keep it coming :) Now I will see if I can talk to Jon about his secret "resource/asset manager" XD
On Apr 21, 2011, at 12:30 AM, Andrew wrote:
So... :)
Don't add a refresh button, tie the code into inotify so you can get a signal when files change in the directory. Should be fairly simple and anything to reduce the complexity of the design the user is a positive.
There are some significant problems with inotify, so I'd recommend
avoid it if
possible.
I really like Martin's idea, that the directory should automatically update when a file is added/removed.
How about Glib::FileMonitor? I haven't used it before, but I just came across it and it looks the part, should work on other platforms as well, rather than inotify which is restricted to Linux.
Yes, that one seems good for now. http://developer.gnome.org/glibmm/unstable/classGio_1_1FileMonitor.html
I'd gone through and updated our dependency page to track: http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies#Distros
That class exists since glibmm 2.16, and the currently supported distros start there, so we're good. We just need to take a little poking about builds on the different platforms to make sure we're covered.
The existing reload checking on images ended up better for that use case to not use it. I'm moving that checking out of SPImage, but for the moment it probably won't match your needs directly, so go ahead and push in with Glib::FileMonitor directly. One suggestion would be to try to keep it separated so that the trigger mechanism can be changed easily later on (don't drop everything in one big method, etc).
Another consideration would be to ensure you "de-bounce" the signaling so that you don't end up trying for force repeated repaints before things are finished. Marking things as dirty and then passing on to an idle callback with some time window can really help. Taking care in that area can really improve the "speed" and responsiveness of the UI.
Hi everyone,
So I have fixed all the bugs that have been found in the Gallery dialog, as well as adding in a Refresh button, as File Monitor that works on all platforms has not yet been found.
All I need now is someone to test on Windows and then it can be merged. Could anyone do this?
Diff on trunk: https://code.launchpad.net/~and471/inkscape/gallery/+merge/58442/+preview-di...
Branch: bzr branch lp:~and471/inkscape/gallery
Thanks
2011/4/26 Andrew <rugby471@...400...>:
Hi everyone,
So I have fixed all the bugs that have been found in the Gallery dialog, as well as adding in a Refresh button, as File Monitor that works on all platforms has not yet been found.
GFileMonitor (wrapped as Glib::FileMonitor in glibmm) does work on all platforms. If kernel-level monitoring support doesn't exist, it will periodically poll the file for changes.
Regards, Krzysztof
On 26/4/11 13:49, Krzysztof Kosiński wrote:
2011/4/26 Andrew <rugby471@...400...>:
So I have fixed all the bugs that have been found in the Gallery dialog, as well as adding in a Refresh button, as File Monitor that works on all platforms has not yet been found.
GFileMonitor (wrapped as Glib::FileMonitor in glibmm) does work on all platforms. If kernel-level monitoring support doesn't exist, it will periodically poll the file for changes.
Did you test it on all platforms Inkscape supports? As discussed on #inkscape (irc) with Andrew and commented in the merge proposal, using GFileMonitor added in r10101 of the branch [1] crashed Inkscape on OS X [2].
Note also that no builds have been done and tested on Windows so far (not with GFileMonitor nor the current solution using a Refresh button).
Sorry if this seems to overrate the importance of supporting other (commercial) platforms, but on irc I voted to implement a solution more likely to work in a cross-platform manner first (with a Refresh button), instead of an auto-refresh (directory monitoring) which crashes Inkscape on other platforms. 'Auto-Refresh' could be added anytime once the branch has been merged into trunk, but the basic features of the new Gallery dialog do not depend on it.
~suv
[1] http://bazaar.launchpad.net/~and471/inkscape/gallery/revision/10101 [2] backtrace: http://pastie.org/1819845
On Tue, 2011-04-26 at 14:18 +0200, ~suv wrote:
Note also that no builds have been done and tested on Windows so far (not with GFileMonitor nor the current solution using a Refresh button).
Sorry if this seems to overrate the importance of supporting other (commercial) platforms, but on irc I voted to implement a solution more likely to work in a cross-platform manner first (with a Refresh button), instead of an auto-refresh (directory monitoring) which crashes Inkscape on other platforms. 'Auto-Refresh' could be added anytime once the branch has been merged into trunk, but the basic features of the new Gallery dialog do not depend on it.
At least hide the button for users with proper operating systems. Forcing everyone to mediocrity can't be the best way.
Inkscape: designed by the lowest common denominator.
Martin,
On 26/04/11 14:27, Martin Owens wrote:
On Tue, 2011-04-26 at 14:18 +0200, ~suv wrote:
Note also that no builds have been done and tested on Windows so far (not with GFileMonitor nor the current solution using a Refresh button).
Sorry if this seems to overrate the importance of supporting other (commercial) platforms, but on irc I voted to implement a solution more likely to work in a cross-platform manner first (with a Refresh button), instead of an auto-refresh (directory monitoring) which crashes Inkscape on other platforms. 'Auto-Refresh' could be added anytime once the branch has been merged into trunk, but the basic features of the new Gallery dialog do not depend on it.
At least hide the button for users with proper operating systems. Forcing everyone to mediocrity can't be the best way.
Inkscape: designed by the lowest common denominator.
The way I see it Martin, is if I put in something that just works for Linux (maybe Windows), then something that works globally will (probably) never get implemented, whereas this way there is an incentive for someone to do this.
I myself only use Inkscape on Linux, so I am not doing this as I want to work on 'my platform' or nowhere - I am doing it as I see it the fairest thing to do for everyone.
Besides it is not that much effort to click a button is it ;)
2011/4/26 Andrew <rugby471@...400...>:
The way I see it Martin, is if I put in something that just works for Linux (maybe Windows), then something that works globally will (probably) never get implemented, whereas this way there is an incentive for someone to do this.
This obviously a bug in GIO which should be fixed, not an indication that GFileMonitor is not cross platform. It would be far better to fix the bug in GIO rather than implement a substandard workaround in Inkscape. You can use the argument both ways: if we put in a workaround, there will be no motivation to fix this GIO bug on OSX.
Regards, Krzysztof
On Tue, Apr 26, 2011 at 8:27 AM, Andrew <rugby471@...400...> wrote:
Besides it is not that much effort to click a button is it ;)
That and UI consistency is something we should try and maintain for our users, people giving help on irc, and for the sake of documentation.
Cheers, Josh
W dniu 26 kwietnia 2011 18:19 użytkownik Krzysztof Kosiński <tweenk.pl@...400...> napisał:
2011/4/26 Andrew <rugby471@...400...>:
The way I see it Martin, is if I put in something that just works for Linux (maybe Windows), then something that works globally will (probably) never get implemented, whereas this way there is an incentive for someone to do this.
This obviously a bug in GIO which should be fixed, not an indication that GFileMonitor is not cross platform. It would be far better to fix the bug in GIO rather than implement a substandard workaround in Inkscape. You can use the argument both ways: if we put in a workaround, there will be no motivation to fix this GIO bug on OSX.
I read the backtrace and it looks like there is some error thrown from Glib::File::monitor_directory. Can you use the C API and call g_error to display what this error is?
Regards, Krzysztof
On Apr 26, 2011, at 4:49 AM, Krzysztof Kosiński wrote:
2011/4/26 Andrew <rugby471@...400...>:
Hi everyone,
So I have fixed all the bugs that have been found in the Gallery dialog, as well as adding in a Refresh button, as File Monitor that works on all platforms has not yet been found.
GFileMonitor (wrapped as Glib::FileMonitor in glibmm) does work on all platforms. If kernel-level monitoring support doesn't exist, it will periodically poll the file for changes.
We've had discussions on this with Andrew in the IRC room.
Basically something is not functioning as documented. So instead of spending his time chasing that rabbit and not being able to get the overall dialog in, it was decided it was best for him to get the main functionality done. As a follow-up it is fairly easy for someone other than Andrew to get rid of the refresh button, especially since I've done this elsewhere in the code base. That allowed Andrew to spend the time he has left focusing on the main new functionality.
So we are aware of the shortcoming and are already working on getting that fixed. It also touches on some functionality I'm adding now (initial push should be ready with only a night or two more work) with beginning a general resource manager. Some of our duplicate code is getting encapsulated over there now, and can include this.
On 26/4/11 18:19, Krzysztof Kosiński wrote:
2011/4/26 Andrew <rugby471@...400...>:
The way I see it Martin, is if I put in something that just works for Linux (maybe Windows), then something that works globally will (probably) never get implemented, whereas this way there is an incentive for someone to do this.
This obviously a bug in GIO which should be fixed, not an indication that GFileMonitor is not cross platform. It would be far better to fix the bug in GIO rather than implement a substandard workaround in Inkscape. You can use the argument both ways: if we put in a workaround, there will be no motivation to fix this GIO bug on OSX.
I don't know whether it is related or indicating an unsupported feature:
Every time the location widget in the standard GtkFileChooser dialog is used on osx (search google, this affects gtk-demo as well as any other GTK+ application), this warning is displayed on the console:
(gtk-demo:87756): Gtk-WARNING **: Unable to find default local directory monitor type
As far as I can tell the error comes from glib/gio: http://git.gnome.org/browse/glib/tree/gio/glocaldirectorymonitor.c?id=2.28.6#n268
Possibly this is related to the failure to monitor a directory with GIO on darwin/osx (another affected application: Raw Therapee [1])? The warnings are not limited to the current stable versions (glib 2.28.6 / gtk2 2.24.4), but have been around apparently since around GTK+ >2.12.9 (according to Google [2]).
~suv
[1] http://rawtherapee.com/forum/viewtopic.php?p=10457#10457 http://code.google.com/p/rawtherapee/source/browse/rtgui/dirbrowser.cc#221 [2] http://www.mail-archive.com/bug-gnubg@...570.../msg03464.html
participants (7)
-
Andrew -
Chris Morgan -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
~suv