Subject: [patch] context-sensitive save and export actions - msg#00087

Previous Message by Date: click to view message preview

Re: Parser error

On Tue, Oct 19, 2004 at 12:17:33AM +0400, Nickolay V. Shmyrev wrote: > The same with changelog. Applied, TNX Geert Stappers signature.asc Description: Digital signature

Next Message by Date: click to view message preview

Re: [patch] context-sensitive save and export actions

On Mon, 2004-10-18 at 18:46 -0400, Douglas Burke wrote: > This is a re-worked version of my previous patch that makes the Save > action (ie menu item and toolbar icon) insensitive if Conglomerate thinks > the document is unchanged. Improvements are: > > - the state is changed via a function call now rather than a macro. > The functions are cong_primary_window_action_set_sensitive() and > cong_primary_window_action_set_label(). I ended up with these names > since they are sent a CongPrimaryWindow as the first argument, but > I also thought about them being called cong_menus* or cong_ui* > > - The "Export" action is now also made inactive if the document does > not have any registered documents. This meant I could remove an > error dialog from cong-file-export.c Thanks for the patch; I hope to have a look at this and commit to both HEAD and WidgetPlayground in the next few days; am trying to fix various last-minute Fedora Core 3 issues right now... > > I thought about checking for whether there are any importers register and, > if not, making the Import item insensitive. However, aren't we know > guaranteed there will be at least one importer plugin (as Conglomerate > comes with several), so we can always assume the Import action is valid? BTW File->Import is a per-application verb, whereas File->Export is a per-document verb. It can't hurt to allow disabling it if no importers; eventually we should allow the user to load/unload plugins at runtime, and so the case where none are available could arise. > > Doug

Previous Message by Thread: click to view message preview

Parser error

Hi, I've just updated and compiled the HEAD branch and conglomerate complains a lot at start up. For instance: Entity: line 103: parser error : error parsing attribute name <name xml:lang="en_GB">Abigail Brady <XXX@XXX> ^ repeated many times. Note the "^" points to the @ character. I found them into dispspecs/kernel-traffic-newsletter.xds but those names come from po/en_GB.po, line 1054. Shouldn't this e-mail format be escaped using the &lt; and &gt; entites? Shouldn't intltool do that automatically? -- Hervé

Next Message by Thread: click to view message preview

Re: [patch] context-sensitive save and export actions

On Mon, 2004-10-18 at 18:46 -0400, Douglas Burke wrote: > This is a re-worked version of my previous patch that makes the Save > action (ie menu item and toolbar icon) insensitive if Conglomerate thinks > the document is unchanged. Improvements are: > > - the state is changed via a function call now rather than a macro. > The functions are cong_primary_window_action_set_sensitive() and > cong_primary_window_action_set_label(). I ended up with these names > since they are sent a CongPrimaryWindow as the first argument, but > I also thought about them being called cong_menus* or cong_ui* > > - The "Export" action is now also made inactive if the document does > not have any registered documents. This meant I could remove an > error dialog from cong-file-export.c Thanks for the patch; I hope to have a look at this and commit to both HEAD and WidgetPlayground in the next few days; am trying to fix various last-minute Fedora Core 3 issues right now... > > I thought about checking for whether there are any importers register and, > if not, making the Import item insensitive. However, aren't we know > guaranteed there will be at least one importer plugin (as Conglomerate > comes with several), so we can always assume the Import action is valid? BTW File->Import is a per-application verb, whereas File->Export is a per-document verb. It can't hurt to allow disabling it if no importers; eventually we should allow the user to load/unload plugins at runtime, and so the case where none are available could arise. > > Doug