Re: Proposal for Introducing a high level framework of concurrent & asynchronous programming
On Tue, Sep 7, 2010 at 9:02 AM, cee1 wrote: > Hi all, > Glib has GMainLoop for asynchronous programming and GThread & GThreadPool > for concurrent programming. To combine the advantages of them two, users > need to take care of threads themselves in sources' callbacks. This > introduces some kind of complexity and also duplicate works. > So introducing a high level framework of concurrent & asynchronous > programming will make writing high performance code more easily. > Apple has made this in its GCD(Grand Central > Dispatch, http://lwn.net/Articles/352978/), and I've written some slides > about it: > > http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch.pdf > http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch-event.pdf > > Here are odp versions: > > http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch.odp > http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch-event.odp > > My ideas are: > > Implement a similar framework in glib. > Make full use of epoll and eventfd, etc. > Rewrite some code in GIO, using this new framework. > Have a look at chergert's Iris library, which heads down the same road you are proposing: http://github.com/chergert/iris > -- > Regards, > - cee1 > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Website proposal for usability
On Wed, Sep 8, 2010 at 1:29 AM, Andreas Nilsson wrote: > On 09/07/2010 04:18 PM, Martyn Russell wrote: >> >> On 09/08/10 22:54, Devin Samarin wrote: >>> >>> I posted this on Bugzilla >>> (https://bugzilla.gnome.org/show_bug.cgi?id=626380) >>> and I was recommended by Martyn to post the details here. >> >> Hi Devin, >> >> I know there isn't much activity on the review here any more, but >> actually, I have been thinking. If people are happy with the work, perhaps >> it makes sense to schedule the move over to the new website to co-inside >> with the release GTK+ 3.0? This is supposed to be towards the end of this >> year. >> >> Any comments on the matter? >> > I think that sounds like a great idea! > - Andreas > Yeah I agree it is a good idea; a fresh new toolkit needs a fresh new website! Plus if there are any new features that may be worth letting people know, there's time to fix it before it's released. Also links like GTK+ 3 documentation and tutorials (for example subclassing the new GTKWidget with gtk_widget_draw()) should be added and I don't think anyone has written those yet. -- Devin Samarin GTK+ is made with a11y in mind, along with i18n and l10n. It offers i14y with every major platform, so v12n is not needed. Its architecture makes it easy to use p13n, however it is not known for its d11n. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Questions about GTK3
On Wed, Sep 8, 2010 at 7:10 AM, Christian Dywan > > So a possible idea would be to turn GtkEditable into a clipboard > interface, where entry specific features are removed. Which features do you consider entry-specific ? As far as I'm concerned, the editable interface could just be implemented by GtkTextView and its derivatives, as well as the other widgets you mentioned. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Questions about GTK3
Am Tue, 7 Sep 2010 20:54:43 -0400 schrieb Matthias Clasen : > > 3) Cleanup of useless classes > > With the removal of the deprecated widgets, we now have objects in > > the widget hierarchy that make no real sense anymore (i.e. GtkItem > > or GtkEditable). Should they be removed? Should they be kept? Is > > anyone working on that or intending to? > > I don't think anybody is. For GtkItem, folding the signals into > GtkMenuItem should be a pretty painless operation, and might be a nice > cleanup. Not sure about GtkEditable. GtkEditable notably features gtk_entry_select_region¹ gtk_editable_get_selection_bounds gtk_editable_insert_text² gtk_editable_delete_text² gtk_editable_get_chars gtk_editable_*_clipboard gtk_entry_set_position¹ gtk_editable_set_editable¹ ¹ GtkEntry had the same functions, they were deprecated. ² GtkEntryBuffer has functions with these names but different semantics. For what I want, the clipboard parts are not specific to entries at all. Consider clipboard functions duplicated in GtkTextBuffer WebKitWebView (GtkTreeView::select-all) GeditView VteTerminal So a possible idea would be to turn GtkEditable into a clipboard interface, where entry specific features are removed. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Website proposal for usability
On 09/07/2010 04:18 PM, Martyn Russell wrote: On 09/08/10 22:54, Devin Samarin wrote: I posted this on Bugzilla (https://bugzilla.gnome.org/show_bug.cgi?id=626380) and I was recommended by Martyn to post the details here. Hi Devin, I know there isn't much activity on the review here any more, but actually, I have been thinking. If people are happy with the work, perhaps it makes sense to schedule the move over to the new website to co-inside with the release GTK+ 3.0? This is supposed to be towards the end of this year. Any comments on the matter? I think that sounds like a great idea! - Andreas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
