Patrick Ohly <patrick.ohly@...> writes: Just becoming a serious pet peeve. Especially because I've spent a helluva lot of time hunting for a solution before I resorted to public wailing. The popups occasionally catch a mouse click, but they also leave the notification icon live tempting me to distraction to check it... I'd be happy to hand edit one of the config(ini) files... I only have one sync peer, so I'm not really qualified to answer per peer/global. If it's straightforward, I would think that separating "info" versus "error" would make a lot of sense. Or is there a way to catch it at the libnotify level (for only syncevo)? (I don't think so...) I really like the software and it works well, but when it's working correctly I wish it would be quiet... Thanks!

Patrick Ohly <patrick.ohly@...> writes: On my multi-monitor godforsaken Gnome3 desktop they appear almost in random locations and sometimes popup and block something I'm trying to click on to get focus because the "focus follows mouse" setting doesn't work so well, if at all. Admittedly some of the popups are also due to email. peer/global. Agreed that user prefs are impossible to predict. If it's not too much coding, many hierarchical config frameworks allow a global setting which can be over-ridden by a per-peer setting. What's the difference between 0 and 2? I would think that 0 = nothing?

On Sa, 2011-12-10 at 13:49 +0100, Patrick Ohly wrote: How about this... First, the current definition of config property (from the 1.2.1 man page): Sync and source configs contain configuration properties. Each property is a name/value pair. Sync properties are used in sync configs, source properties in source configs. The names were chosen so that they are unique, i.e., no sync property has the same name as a source property. A property can be unshared (has separate values for each peer, therefore sometimes also called per-peer; for example the uri property which defines the remote database), shared (same value for all peers; for example the database property for selecting the local database) or global (exactly one value). Let's extend that: In cases where it makes sense (for example, the logging level), the property value can be set at all of the different levels. The most specific value then will be used (per-peer overrides shared, shared overrides global). The name of a property without any specific prefix refers to the value at its most specific level. The "global", "shared", resp. "unshared" prefixes select a certain level. For example: globalLogLevel = 4, sharedLogLevel = 3 and logLevel = 2 result in a logging level of 2 for the peer. "unsharedLogLevel" could have been used instead of "logLevel". The command line would be extended to list at which levels a property can be set and what values it has where: $ syncevolution --sync-property ? [...] loglevel (0, unshared, global) <=== "global" is new level of detail for log messages: - 0 (or unset) = INFO messages without log file, DEBUG with log file - 1 = only ERROR messages - 2 = also INFO messages - 3 = also DEBUG messages [...] remoteDeviceId (no default, unshared) SyncML ID of our peer, empty if unknown; must be set only when the peer is a SyncML client contacting us via HTTP. Clients contacting us via OBEX/Bluetooth can be identified either via this remoteDeviceId property or by their MAC address, if that was set in the syncURL property. [...] All source properties would remain as they are. I don't see a need to change any of them. The following sync properties would become multi-level: logdir (no default, shared, global) loglevel (0, unshared, shared, global) printChanges (TRUE, unshared, shared, global) dumpData (TRUE, unshared, shared, global) maxlogdirs (10, shared, global) useProxy (FALSE, unshared, shared, global) proxyHost (no default, unshared, shared, global) proxyUsername (no default, unshared, shared, global) proxyPassword (no default, unshared, shared, global) SSLServerCertificates (/etc/ssl/certs/ca-certificates.crt:/etc/pki/tls/certs/ca-bundle.crt:/usr/share/ssl/certs/ca-bundle.crt, unshared, global) Instead of blindly making all properties configurable at all levels, I tried to find those where there are valid use cases. For example, I left the auto sync settings per-peer only because the selection of which transport to do auto sync on is peer-specific. The timing values might be shared, but even that is uncertain. Printing a config would show all levels like this: # level of detail for log messages: # - 0 (or unset) = INFO messages without log file, DEBUG with log file # - 1 = only ERROR messages # - 2 = also INFO messages # - 3 = also DEBUG messages # > 3 = increasing amounts of debug messages for developers loglevel = 4 # sharedLoglevel = # globalLoglevel = Or like this, when set only at the outer level: # level of detail for log messages: # - 0 (or unset) = INFO messages without log file, DEBUG with log file # - 1 = only ERROR messages # - 2 = also INFO messages # - 3 = also DEBUG messages # > 3 = increasing amounts of debug messages for developers # loglevel = # sharedLoglevel = globalLoglevel = 4 Setting it would be done like this: $ syncevolution --configure loglevel= globalLogLevel=4 <config> It is impossible to distinguish between setting loglevel to an empty value (and thus the default) and unsetting it (which in this case means falling back to the global value). The current implementation sets the empty value. It is not possible to unset a property. I propose to change the interpretation of "empty value" to "unset the property". That covers the command line. In the D-Bus API the additional values show up as if they were new properties. Under the current rules a D-Bus client already must preserve them. Because the traditional names are defined so that they override the other values, a client which only knows how to set the traditional values will still do the right thing - almost. Setting them has the desired effect, but when reading the current value it is no longer enough to look at just "loglevel". If that is unset, the client also has to check "sharedLoglevel" and "global"Loglevel". Having said that, the GTK sync-UI doesn't do anything like that and thus doesn't have to be adapted. Yes. With that in mind the full definition would be: notifyLevel (3, unshared, shared, global): Level of detail for desktop notifications. Currently such notifications are generated only for automatically started sync sessions. 0 - suppress all notifications 1 - show only errors 2 - show information about changes and errors (same as level 3 at the moment) 3 - show all notifications, including starting a sync Does this all make sense so far? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.

On Do, 2011-12-15 at 10:20 +0000, Brian wrote: That's the right solution for solving just this problem. That's what I am doing now, triggered but not justified by your use case alone ;-) The basic question is: will the result be too complicated to use or does the additional functionality justify the increased complexity? I find it useful, but I'm not sure about the complexity. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.