Performance of GMainLoop
Hello! I'm working on network application (both server and client). I decided to implement asynchronous socket in my code. I want do this using GMainLoop to avoid writing multi thread application. I will add new GSource to main GMainContext, which will handle each socket or add one GSource, which will handle many sockets. Of course all sockets will be non-blocking. I'd like to now how many sockets GMainLoop can handle to avoid problems with performance. Were there any test made for that? Second thing is GMainLoop's code. I'd like to know how it works. I read code, but it isn't to understand it for me. Are there any articles about it or so interesting threads in mailing list's archive? If i will find something interesting in archive, please tel me where and around which date should I search for it. -- Cya! Tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Not show selection of a tree view column
On Thu, 2007-07-26 at 15:06 +0100, Dave Howorth wrote: Peter Clifton wrote: I think a brand new widget might be needed - one which has a more table like rendering model. I presume a GtkTable isn't table-like enough :) GtkTable is a container for widgets, and (as far as I know) doesn't support cell renderers, nor a model based backend. I think what both use-cases want is a GtkTreeView which supports certain cells spanning multiple columns or rows. Obviously this doesn't fit well into the existing MVC + API. Thanks for the thought though. Another thing I briefly considered was GtkSheet, but its a bit too spread-sheet like, and again IIRC, doesn't support standard GtkCellRenderers which would be a big plus. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Not show selection of a tree view column
On 7/26/07, Peter Clifton [EMAIL PROTECTED] wrote: I love the screen-shots, but I fear doing this properly is something which GtkTreeView can't do. In an application I'm working on, I would really love to use a row which spans columns for the purpose of rendering a: Click here to add new field row. I unfortunately ended up having to put a (much shorter) text in the first column. This won't help your problem, but a possible workaround for mine is to get the coordinates of where certain rows are, and line up a widget to those coordinates OUTSIDE of the treeview. That might be my best bet. However, it was still really cool to write this renderer, maybe I'll polish it up a bit and post it if anyone's interested. dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Not show selection of a tree view column
Hi folks, Was wondering if it was possible to have a column omitted from the selection bar in a gtk treeview. I've made a custom renderer which displays a strip of an image, so you can split that image over a number of rows. It looks terrible with selection rectangles behind it, even worse with the dotted highlight rectangle that occurs when using the keyboard to focus a row. I'd like to be able to tell gtk to not select that row at all. Any ideas? Another possible idea would be that I have my custom renderer wrong, drawing on the wrong thing or wrong layer, not too sure about that. Maybe it is possible to use the custom renderer to draw the selection rectangle too? More description and (pretty?) screenshots can be found on my blag: http://d.minuslab.net/?p=43 thanks in advance. dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Performance of GMainLoop
Tomasz Jankowski wrote: Second thing is GMainLoop's code. I'd like to know how it works. I read code, but it isn't to understand it for me. Are there any articles about it or so interesting threads in mailing list's archive? If i will find something interesting in archive, please tel me where and around which date should I search for it. The main loop is basically a select() call under linux. A convenient one. This means that each main loop iteration calls select with a bunch of file descriptors to listen (X server socket and other sources). If one of them has data the handler for this source is called, otherwise there is a timeout that triggers the timeout events and other timed events. So the performance should be equally to a simple select call reduced a bit with overhead of the main loop context handling. Note: I'm not a glib specialist. Cheers, Andy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Not show selection of a tree view column
Peter Clifton wrote: I think a brand new widget might be needed - one which has a more table like rendering model. I presume a GtkTable isn't table-like enough :) Cheers, Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Not show selection of a tree view column
On Thu, 2007-07-26 at 09:35 -0400, Dave Foster wrote: Hi folks, Was wondering if it was possible to have a column omitted from the selection bar in a gtk treeview. I've made a custom renderer which displays a strip of an image, so you can split that image over a number of rows. It looks terrible with selection rectangles behind it, even worse with the dotted highlight rectangle that occurs when using the keyboard to focus a row. I'd like to be able to tell gtk to not select that row at all. Any ideas? Another possible idea would be that I have my custom renderer wrong, drawing on the wrong thing or wrong layer, not too sure about that. Maybe it is possible to use the custom renderer to draw the selection rectangle too? More description and (pretty?) screenshots can be found on my blag: http://d.minuslab.net/?p=43 I love the screen-shots, but I fear doing this properly is something which GtkTreeView can't do. In an application I'm working on, I would really love to use a row which spans columns for the purpose of rendering a: Click here to add new field row. I unfortunately ended up having to put a (much shorter) text in the first column. I get the feeling that too much of GtkTreeView's implementation is private to be able to subclass it and provide this additional functionality, not to mention that its rendering model is very specific to columns. I think a brand new widget might be needed - one which has a more table like rendering model. It might be possible to start from GtkTreeView's code - but its a scary C file, and I quickly realised I didn't have the time / knowledge to write the new widget myself. Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: printing dialog update...
Hey Sean, third time lucky. I've said it before on your blog, and I'll say it again: The drop-down for printer selection WILL NOT WORK! there is no need to shout. From working on this project with the pros from the printer manufacturers, I know that there are organisations where all worldwide printers live in the same network zone. That is 10.000 (or was it 100.000) printers. That pop-up list will contain the printers that are installed, not all the ones on the network. The (currently giant mess of) installation of printers will be dealt with in the next phase of the project, including using using different printers every day: http://www.mmiworks.net/eng/publications/2006/10/preparing-for- openprinting-lexington.html#newpat The tags that look like links but aren't are still funny looking, too. There has to be a better way to do that which doesn't trample established UI expectations. The tags need some polish, sure. The example preview widget is useless in so many cases. Anyone doing booklet printing or many other kinds of professional publishing drafting needs to be able to see side-by-side pages. I did remind us all in the last blog entry that the print dialog shown there is for general inkjet. The one for high volume printers with booklet making will be dealt with later. One size does not fit all. Now, that's my comments and the minor things wrong with the design. There's more to it than that, though. The whole approach is just wrong. The idea of letting the printer manufacturers decide _anything_ about the UI is just terrifying. But they do already at the moment. They fill tabs with options. They decide whether a dialog is the one for a general inkjet or a high volume machine. So what's new? LWe don't need those people deciding what tags and option sets to stuff into the UI I say in general that engineers should not take user interaction decisions, yeah. Instead of just stuffing a bunch of tags into the UI, why not come up with an actual user-study-based idea of what 90% of users need to do, come up with a solid (and tested) UI for them, and then add in an easy way to access the extra tags/options for users that need the extra printer control? With user centred design is how the usability professionals in my team started last year spring at the openPrinting Atlanta summit. That came to a grinding halt when they realised that there are 5,000,000 use cases (no joke). Printing is generic infrastructure. That's when they got me involved, to solve it architecturally. We will use usability surveys to decide on the tags. We will use usability tests to validate every bit of our design. And that will terminate endless discussions with engineers whether this new approach is going to work. Let some actual UI designers figure out how to deal with the WHOLE printing config process, hey, that's me and my team. thanks for the support. And for the rest. My team will design complete solutions for the seven printer clusters: http://wiki.openusability.org/printing/index.php/Printer_type_clusters I can only cajole printer manufacturers into working with interaction and usability professionals when doing their own dialog config. If they don't, and that will happen, the engineering types will work as usual. They will start with one of the seven designs, take it as the word of god, and change as little as possible, in order 'not to break it.' Fine, suits me. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib build fixes for visual c++
Hi Lieven, Look under build/win32/dirent/ in the glib source, there is a dirent there. / Cody On Thu, 2007-07-26 at 23:11 +0200, Lieven van der Heide wrote: Hi, I made some buildfixes for glib under visual studio. It's mostly related to gdir.c, which required the dirent.h file, which did seem to be present in the win32 versions of gcc, but not in visual c++. I used the code from http://www.softagalleria.net/dirent/index.en.html, and modified it a bit so that it works with utf-8. I think it's a good idea to just keep this file in the glib repository. Greets, Lieven van der Heide ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Glib build fixes for visual c++
Hi, I made some buildfixes for glib under visual studio. It's mostly related to gdir.c, which required the dirent.h file, which did seem to be present in the win32 versions of gcc, but not in visual c++. I used the code from http://www.softagalleria.net/dirent/index.en.html, and modified it a bit so that it works with utf-8. I think it's a good idea to just keep this file in the glib repository. Greets, Lieven van der Heide vc_buildfixes.patch Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
