FlexRSS plugin

[markybob]

You're right. But, now that you mention it, you can't do anything in the main deluge window, either, so I have a guess as to what is happening...

I'm noticing that everything is a GtkDialog, which, when you call gtk_dialog_run() (or gtk.Dialog.run() in python) "Blocks in a recursive main loop until the dialog either emits the "response" signal, or is destroyed." (http://developer.gnome.org/doc/API/2.0/ ... dialog-run). Everything else seems to work because they are also GtkDialogs. This doesn't seem like proper behavior to me, and, after playing around with a few other gnome apps, it doesn't seem to be the standard behavior.

Anyways, IMHO most of these GtkDialogs (browsing through the glade directory now) should really be GtkWindows. At the very least, a *lot* of gtk_dialog_run() calls should be removed. If you disagree, I can re-work my plugin to use a dialog instead... I'm just not sure this is the best solution.

right, but not being able to do something on the main client is intentional. look at the blocklist plugin or any other plugin that has a preference, you shouldnt have to close out the main plugin manager to edit those preferences. it just seems silly

[daddy]

right, but not being able to do something on the main client is intentional.

That seems silly to me, and is inconsistent with every other gnome application I've tried. Quoting from the GNOME Human Interface Guidelines 2.0, Chapter 1:

Remember that computers exist to serve humans. A user should always feel in control, able to do what they want when they want. This means you should generally avoid modes; users should be able to switch between different tasks (and specifically, different windows) at any time. See the section called “Modality” for more information on modes.

And from "the section called “Modality”":

A non-modal window does not restrict the user's interaction with other open windows on the desktop in any way. Using non-modal windows gives the user maximum flexibility to perform tasks within your application in any order and by whichever means they choose.

An application modal window, while it is open, prevents the user from interacting with other windows in the same application.

A system modal window, while it is open, prevents the user from interacting with any other window in any application, including the desktop itself.

Guidelines

• Use an application modal window only if allowing interaction with other parts of the application while the window is open could cause data loss or some other serious problem. Provide a clear way of leaving the modal window, such as a Cancel button in an alert.
• Do not use system modal windows.

As I said, I'm willing to change the behavior of my plugin if that is what you want, but my opinion is that doing so would be working around a bug in deluge, when I would rather fix the bug (yes, I'm willing to help). It's up to you.

look at the blocklist plugin or any other plugin that has a preference, you shouldnt have to close out the main plugin manager to edit those preferences. it just seems silly

I agree, but I think the proper solution is using non-modal windows, not further boxing the user into my configuration screen. For example, what if they want to copy and paste a bunch of feeds from SatNav's plugin into mine (or vise versa)? As it stands, they have to open one plugin's configuration screen, copy the URL, close the window, open the other plugin, paste it, close the window, repeat. If there is no compelling reason for blocking other windows, it seems silly to do so.

BTW, maybe we should move this to the development forum? Up to you.

[SatNav]

Hey,

Just downloaded FlexRSS and had a play. I like it very much. It goes to show how much people wanted RSS support, for there to be three plugins in development at once (I believe Jorge Vargas is, or was, working on one as well).

I really like some of the features you've implemented, particularly the one that allows you to generate a filter from a feed entry (I know virtually nothing about using regular expressions), and I'm impressed at the date/episode handling stuff you've done.

I think now that this is out (or nearly, at least - better shift if you wanna beat the Gutsy cut-off ) I'll probably leave mine pretty much as is. I was planning to implement some requested features, even though I didn't need them, but now I doubt I'll bother. I'll leave mine as a 'simple' broadcatcher, and let you shoulder the load of maintaining an 'advanced' one . Though I might stick my oar in from time to time...

Nice job!

[markybob]

right, but not being able to do something on the main client is intentional.

That seems silly to me, and is inconsistent with every other gnome application I've tried. Quoting from the GNOME Human Interface Guidelines 2.0, Chapter 1:

Remember that computers exist to serve humans. A user should always feel in control, able to do what they want when they want. This means you should generally avoid modes; users should be able to switch between different tasks (and specifically, different windows) at any time. See the section called “Modality” for more information on modes.

And from "the section called “Modality”":

A non-modal window does not restrict the user's interaction with other open windows on the desktop in any way. Using non-modal windows gives the user maximum flexibility to perform tasks within your application in any order and by whichever means they choose.

An application modal window, while it is open, prevents the user from interacting with other windows in the same application.

A system modal window, while it is open, prevents the user from interacting with any other window in any application, including the desktop itself.

Guidelines

• Use an application modal window only if allowing interaction with other parts of the application while the window is open could cause data loss or some other serious problem. Provide a clear way of leaving the modal window, such as a Cancel button in an alert.
• Do not use system modal windows.

As I said, I'm willing to change the behavior of my plugin if that is what you want, but my opinion is that doing so would be working around a bug in deluge, when I would rather fix the bug (yes, I'm willing to help). It's up to you.

look at the blocklist plugin or any other plugin that has a preference, you shouldnt have to close out the main plugin manager to edit those preferences. it just seems silly

I agree, but I think the proper solution is using non-modal windows, not further boxing the user into my configuration screen. For example, what if they want to copy and paste a bunch of feeds from SatNav's plugin into mine (or vise versa)? As it stands, they have to open one plugin's configuration screen, copy the URL, close the window, open the other plugin, paste it, close the window, repeat. If there is no compelling reason for blocking other windows, it seems silly to do so.

BTW, maybe we should move this to the development forum? Up to you.

thanks for the lesson on modality, but modal isnt being set at all. take a look for yourself if you dont believe me.

[daddy]

thanks for the lesson on modality, but modal isnt being set at all. take a look for yourself if you dont believe me.

You're welcome, but it *is* being set. Take a look at gtk_run_dialog() (in gtkdialog.c, lines 1003-1005 of revision 18349) if you don't believe me. Or, to spare you the trouble:

was_modal = GTK_WINDOW (dialog)->modal;
if (!was_modal)
gtk_window_set_modal (GTK_WINDOW (dialog), TRUE);

[daddy]

Just uploaded a new version--the only change is that feeds are retrieved/parsed in their own thread.

markybob, do you have a decision on what to do re: modality? Should I make my plugin modal or fix deluge to not be? Also, any thoughts on the patch I posted on July 23 (with version 0.0.2) to allow plugins to specify the path?

[markybob]

Just uploaded a new version--the only change is that feeds are retrieved/parsed in their own thread.

markybob, do you have a decision on what to do re: modality? Should I make my plugin modal or fix deluge to not be? Also, any thoughts on the patch I posted on July 23 (with version 0.0.2) to allow plugins to specify the path?

i just committed the patch to allow plugins to specify the path. i'll gladly accept and commit a patch to fix deluge

[daddy]

Okay, two patches, one to make the plugins dialog non-modal, the other to make individual plugins' dialogs non-modal.

Edit: added a third patch, which fixes the preferences dialog. It also includes the plugins dialog fix because I was too lazy to separate them. If its a problem, let me know.

[markybob]

Okay, two patches, one to make the plugins dialog non-modal, the other to make individual plugins' dialogs non-modal.

Edit: added a third patch, which fixes the preferences dialog. It also includes the plugins dialog fix because I was too lazy to separate them. If its a problem, let me know.

committed, thanks.

[markybob]

0.0.5 with svn trunk at least doesnt unload when the plugin is disabled in the plugin manager