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,

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

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

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

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 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 ;)

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 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

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.