Re: Librsvg 2.40.7 is released
Hi: As for rendering bugs, do you have any favorites? Yes, animation using JavaScript scripting, tho I can see the hard of this librvsg doesnt support it as of today, and it would be great to have. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
Hi: I would like to keep it for both Contacts (gnome-contacts) and Calendar (gnome-calendar). I've been trying to follow this bug triage guidelines [1], and for me it means bugs I haven't even look at. Once I look at a bug, I move it into NEW, but it serves organizational purposes. [1]: https://wiki.gnome.org/AllanDay/BugManagement ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Search Providers
Hi: You could get the best of both worlds by doing what gnome-documents does (ie. use an inactivity-timeout): https://git.gnome.org/browse/gnome-documents/tree/src/application.js#n133 That way, your process does not linger for ever, but it stays around long enough to cache a quick series of searches. That would present the same problem initially. We would want the app to return the search results as fast as it can, but since it takes some times to load the machiney initially, the user would have to type his query, wait a few seconds for the first results and then, after that, the querying will get a better, snappier. And this makes me think on when does gnome-shell span its gnome-shell-calendar-server. I'm thinking about those applications on Windows that registers itself to be started at launch. Do we want that for our users? Or it's better to slow search at times. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Search Providers
Hi: I thought initially of mailing this to gnome-shell list, but after a bit of thought I think it belongs here instead. I have the case of two applications: Contacts and Calendar and its search-providers. The case is that those two when launched in order to perform a search need to connect to eds and perform long time running operations. Contacts needs to connect to Folks which in turn connects to EDS services and then make the matching, and Calendar connects to EDS to create calendar-client and query the calendars for the range inspected. It is then, when the applications are ready to execute some search. My idea was to have them (the app, which provides search at the same time) running all the time in the background, but that feels like using the resources of the CPU without the user knowing. True, the user can do some digging and disable the search-providers if he feel some lagging or wasting of resources, but I'm not so sure. Good defaults is what we should do right? That brings me to: what would be the best course of action here? A final note about this: both apps would benefit from being running perpetually; the launch time would shorten by a lot, because we would just need to create the windows. Erick PS: I have no idea of what the epiphany search providers does, but I guess something like this would happens if it would provides search thourgh Google or the search-engine of choice. PSS: Right now Contacts makes a full launch on every call to its search-provider. This could improve once Folks gains a matching cache, but that's not close at leat for now. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A last blocker review for 3.8
It's possible that this is due to a performance issue in libfolks. We've been picking up performance work lately (starting with adding some profiling tests to our test suite), so we'll hopefully be in much better shape for 3.10. The main bugs to keep an eye on are bgo#689549 and bgo#687671. But as far as blockers, this and the other performance bugs won't be fixed by Monday, but hopefully within the next month or so. -Travis What I'm worried about is about we can improve performance a bit before 3.8.1 or we might have to left that work pending for the next cycle. And I'm including myself, since I will need to fully profile Contacts to find out to slow paths. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Calendar app and tasks
I hope. Eventually. Just curious - is there a plan to integrate tasks in future Calendar app? https://live.gnome.org/Design/Apps/Calendar Right now I'm a little short of time. But I'll keep working on it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Introducing Calendar
Hi: Some time ago I started coding Calendar application for Gnome as sketched here[1] Currently the application does some pretty simple stuff, like showing the events of calendars suscribed in Evolution for the actual month. The rests of the views has to be added/coded yet, but I think the architecture design is almost completed. The code is hosted for now at Github[2] cause doesn't have a release yet as stated here[3], anyway I'll talk with the admins of git.gnome.org Now, the call for help is for someone on the Design Team to step forwward to take care of the design parts of the development since I must confess I'm pretty bad at that, and I have some concerns with the mockups posted on the wiki. So, I'll keep up updated. [1]: https://live.gnome.org/Design/Apps/Calendar [2]: https://github.com/erick2red/gnome-calendar [3]: https://live.gnome.org/ProjectPrerequisites ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sharing widgets between GNOME 3 applications
The way I see it, is that we need to provide some widgets to do the stuff following the guldelines of the new Gnome Design As Allan says here [1], there's a new kind of toolbar, which have some stuff in common, and it will be worthy to look into the possibility of make a specific widget for it, and the sames goes for those new kinds of iconviews, and for the selection patterns as well. [1](http://afaikblog.wordpress.com/2012/02/10/a-new-approach-to-gnome-application-design/) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
