[Gnome-zeitgeist] [Bug 663654] [NEW] dark text on dark background using dark background white text theme
Public bug reported: Gnome activity journal uses a fixed font colour for the name of the files it displays and when using a dark background theme the text is only possible to see when hovering over the name of the file. also effect's the date ** Affects: gnome-activity-journal Importance: Undecided Status: New -- dark text on dark background using dark background white text theme https://bugs.launchpad.net/bugs/663654 You received this bug notification because you are a member of GNOME Zeitgeist Team, which is the registrant for GNOME Activity Journal. Status in GNOME Activity Journal: New Bug description: Gnome activity journal uses a fixed font colour for the name of the files it displays and when using a dark background theme the text is only possible to see when hovering over the name of the file. also effect's the date ___ Mailing list: https://launchpad.net/~gnome-zeitgeist Post to : gnome-zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~gnome-zeitgeist More help : https://help.launchpad.net/ListHelp
[Gnome-zeitgeist] [Bug 663654] Re: dark text on dark background using dark background white text theme
** Attachment added: gnome-activity-journal text bug screenshot https://bugs.launchpad.net/bugs/663654/+attachment/1702418/+files/gnome-activity-journal_text_bug.png -- dark text on dark background using dark background white text theme https://bugs.launchpad.net/bugs/663654 You received this bug notification because you are a member of GNOME Zeitgeist Team, which is the registrant for GNOME Activity Journal. Status in GNOME Activity Journal: New Bug description: Gnome activity journal uses a fixed font colour for the name of the files it displays and when using a dark background theme the text is only possible to see when hovering over the name of the file. also effect's the date ___ Mailing list: https://launchpad.net/~gnome-zeitgeist Post to : gnome-zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~gnome-zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] Translation template import - zeitgeist in Zeitgeist Framework 0.1
Hello Zeitgeist Framework Team, On 2010-10-19 08:06z (4 minutes ago), you uploaded a translation template for zeitgeist in Zeitgeist Framework 0.1 in Launchpad. The template has now been imported successfully. Thank you, The Launchpad team ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] Translation template import - zeitgeist in Zeitgeist Framework 0.5
Hello Zeitgeist Framework Team, On 2010-10-19 10:48z (3 minutes ago), you uploaded a translation template for zeitgeist in Zeitgeist Framework 0.5 in Launchpad. The template has now been imported successfully. Thank you, The Launchpad team ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] Translation template import - zeitgeist in Zeitgeist Framework 0.3
Hello Zeitgeist Framework Team, On 2010-10-19 10:48z (3 minutes ago), you uploaded a translation template for zeitgeist in Zeitgeist Framework 0.3 in Launchpad. The template has now been imported successfully. Thank you, The Launchpad team ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] Translation template import - zeitgeist in Zeitgeist Framework 0.1
Hello Zeitgeist Framework Team, On 2010-10-19 10:48z (4 minutes ago), you uploaded a translation template for zeitgeist in Zeitgeist Framework 0.1 in Launchpad. The template has now been imported successfully. Thank you, The Launchpad team ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 663205] [NEW] make sure all dataproviders use RegisterDataSource
*** This bug is a duplicate of bug 602864 *** https://bugs.launchpad.net/bugs/602864 Public bug reported: For consistency we should make sure that each Dataprovider uses RegisterDataSource. ** Affects: zeitgeist-dataproviders Importance: Undecided Status: New ** This bug has been marked a duplicate of bug 602864 Data-sources don't identify themselves to Zeitgeist * You can subscribe to bug 602864 by following this link: https://bugs.edge.launchpad.net/zeitgeist-dataproviders/+bug/602864/+subscribe -- make sure all dataproviders use RegisterDataSource https://bugs.launchpad.net/bugs/663205 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Data-Sources. Status in Zeitgeist Data-Sources: New Bug description: For consistency we should make sure that each Dataprovider uses RegisterDataSource. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 639737] Re: Improve insertion times
OK I worked out the synchronous = NORMAL pragma for a week now and actually broke my netbook. What I learned is you have a better chance of messing up your partition than using synchronous = NORMAL. The deal breaker is the improvement is not noticeable unless we use journal = WAL However we are facing the issue that WAL and is not supported in older sqlite. What do we do? -- Improve insertion times https://bugs.launchpad.net/bugs/639737 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: In Progress Bug description: We insert pretty slowly with an average of 0.15 seconds for one event on my core i5 2.5 GHz beast. RainCT had some optimization possibilities: 1) PRAGMA synchronous=OFF 2) PRAGMA journal_mode=OFF The Chat: kamstrup I think we are - but I can't recall... in case of failed transactions - but I don't even know if we use transactions these days... seif RainCT try synchronous=OFF seif RainCT but it can corrupt your database if your phone dies while ZG is inserting seif RainCT and journal_mode=MEMORY seif RainCT or OFF since we don't use rollback anyway seif so maybe journal_mode = OFF is a good start? kamstrup okay, he's probably right... kamstrup 'grep -Ri rollback _zeitgeist/' is your friend :-) kamstrup apparently we are not using rollback... More info can be found here: http://www.sqlite.org/pragma.html In order to get a better picture of what's going on, can you please try to get some more information, like: 1) How many events are in your database? 2) What's the insertion time for one event into an empty db? 3) Out of this 0.15 secs, how many time is spend in our python code, and what's the time of the actual sql action? 4) How much faster is adding 10 events at once compared to adding them one at a time? 5) You think 0.15 secs is slow for inserting one event, what time do you expect, and why? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 663475] [NEW] fts returning same subjects for Relevancy queries
Public bug reported: I'd be nice to add a new ResultType for FTS - SUBJECT_RELEVANCY. A little talk on IRC: mhr3 kamstrup, it's a bit weird that when using ResultType.RELEVANCY, the same subjects get returned multiple times kamstrup mhr3: that'll be hard to fix when you think about it it's really the right thing we do imho mhr3: it's relevancy ordered search over the events kamstrup not the subjects mhr3 kamstrup, otoh most of the data that gets indexed comes from the subject kamstrup mhr3: perhaps you want a a ResultType.SUBJECTS_BY_RELEVANCY mhr3 yea, i guess i do kamstrup mhr3: i agree with the general idea that clustering on subject would be nice ** Affects: zeitgeist-extensions Importance: Undecided Status: New -- fts returning same subjects for Relevancy queries https://bugs.launchpad.net/bugs/663475 You received this bug notification because you are a member of Zeitgeist Extensions, which is the registrant for Zeitgeist Extensions. Status in Zeitgeist Extensions: New Bug description: I'd be nice to add a new ResultType for FTS - SUBJECT_RELEVANCY. A little talk on IRC: mhr3 kamstrup, it's a bit weird that when using ResultType.RELEVANCY, the same subjects get returned multiple times kamstrup mhr3: that'll be hard to fix when you think about it it's really the right thing we do imho mhr3: it's relevancy ordered search over the events kamstrup not the subjects mhr3 kamstrup, otoh most of the data that gets indexed comes from the subject kamstrup mhr3: perhaps you want a a ResultType.SUBJECTS_BY_RELEVANCY mhr3 yea, i guess i do kamstrup mhr3: i agree with the general idea that clustering on subject would be nice ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 643303] Re: Upgrade of the db schema strategy for version jumps
Here is a little python file Markus wrote that might be useful for this bug. ** Attachment added: pathfinder.py https://bugs.edge.launchpad.net/zeitgeist/+bug/643303/+attachment/1702115/+files/pathfinder.py -- Upgrade of the db schema strategy for version jumps https://bugs.launchpad.net/bugs/643303 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: Triaged Bug description: We have to discuss how to support versions jump in the upgrade path of our db schema, like from (core, 0) to (core, 2). This becomes even more important when we reach the next version. For me there are two solution: 1.) write 'dummy' upgrade scripts, like core_0_2.py, which do not more than running core_0_1.run() and core_1_2.run() one after another 2.) add some magic to sql._do_schema_upgrade() which automatically tries to find an upgrade path and run the 'shortest' possible one. There is an issue with both solutions: right now the upgrade mechanism is designed in a way that after each data upgrade the schema upgrade is done. In both solutions the schema upgrade will be done *after* the full upgrade path. This can be handled by solution 1.) in the sanest possible way, the downside is that 1.) does not scale well for big numbers of schema versions around. Any Ideas? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
