Re: RFC: GtkPreview library
Cosimo Cecchi cosi...@gnome.org writes: On Tue, Jan 20, 2015 at 10:24 AM, Carlos Garcia Campos carlo...@gnome.org wrote: One important thing is that preview providers should be out of process, since unfortunately it's very easy to make things crash with buggy files (which are very common). That could be done by every provider, but if we force that at a higher level it would be much better. That would also ensure that preview providers don't block the UI main thread, assuming the communication with the provider processes will be always asynchronous unconditionally. I ultimately agree, and I wrote a paragraph to that effect in my proposal... It's tricky to enforce this in the library, because it effectively means inventing a way for a process to draw into another process that doesn't look like libbonobo, and I didn't really want to go that path... I'm assuming the providers will render the contents into surfaces that the previewer will compose, not providers directly drawing into the previewer. We can share the bitmaps between processes without using anything like CORBA, simply using shared memory and sending the file descriptor with dbus. Note that providers might not be asynchronous, or thread safe. Cosimo -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Commercial support page on gtk.org
Excerpts from Martyn Russell's message of mar mar 20 11:50:52 +0100 2012: On 19/03/12 15:30, Carlos Garcia Campos wrote: Comments welcome, It looks pretty good :-) Attached is a patch to add Igalia to the list of companies. Committed, should be on the test server now. Sorry, Igalia should have been an obvious company to add to that list. No problem, thanks! -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Commercial support page on gtk.org
Excerpts from Martyn Russell's message of lun mar 19 16:12:32 +0100 2012: Hi all, For a while, I/we at Lanedo have thought that gtk.org is missing a commercial support page. Qt has one and it's even been requested by some clients in the past IIRC. I've been meaning to merge this branch for a while: http://git.gnome.org/browse/gtk-web/log/?h=support The result is demonstrated here: http://curlybeast.net:8080/support.php I made a few small changes today and am happy with it myself. Just so people know, the list of companies is randomly listed, so there is no bias about ordering here. If there are no major objections, I will push this by Friday this week or shortly after. Comments welcome, It looks pretty good :-) Attached is a patch to add Igalia to the list of companies. Regards, -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 0001-support-Add-Igalia-to-the-list-of-companies.patch Description: Binary data signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Multitouch review 2: press-and-hold
Excerpts from Bastien Nocera's message of mié feb 01 12:23:52 +0100 2012:
On Tue, 2012-01-31 at 19:18 -0500, Matthias Clasen wrote:
API:
GtkWidget::press-and-hold
GTK_PRESS_AND_HOLD_{QUERY,TRIGGER,CANCEL}
GTK_STYLE_CLASS_PRESS_AND_HOLD style class
GtkSettings::gtk-press-and-hold-timeout setting
This feature has a long history going back to 2005 and Hildon [1][2].
The way it works is that ::press-and-hold is emitted upon button
press (only button 1), scroll or touch events with an action of
GTK_PRESS_AND_HOLD_QUERY. Widgets have to opt-in to press-and-hold by
handling that and returning TRUE. GTK+ then plays the press-and-hold
animation (which is adapted to whether you are using a tiny cursor or
a fat thumb). If you hold still until the time determined by
gtk-press-and-hold-timeout has passed, ::press-and-hold is emitted
again with the TRIGGER action, and widgets are expected to handle that
by doing whatever action they want to tie to long presses. If the
press-and-hold is canceled because the pointer was moved (beyond the
drag threshold), ::press-and-hold is emitted with the CANCEL action.
If the widget goes away while the press-and-hold animation is running,
it gets removed and cleaned up.
One interesting aspect here is that ::press-and-hold is emitted on the
target widget of the event before the capture phase. There is a
comment in the code that explains that this is 'so a parent capturing
events doesn't delay nor prevent a child from doing the press-and-hold
action'.
Questions, comments:
I still think that the press and hold animation has no place here. Apart
from Windows, I've not seen any touch or stylus devices use this, and I
seriously doubt its usefulness (versus it looking tacky, out of place,
etc.).
IIRC, animation will only work if GtkSettings:gtk-enable-animations is TRUE.
Can we please get the code writers' reasoning behind having this
animation?
I think it gives good feedback that something is going to happen, and
when.
What do the designers think? Should it be something the theme
chooses to implement (so that the Windows theme would use the Windows
animation for that for example)?
Yes I think I added a style class for press and hold animation, so
it's themable.
Cheers
--
Carlos Garcia Campos
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462
signature.asc
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkApplication and argc/arv
Excerpts from Tristan Van Berkom's message of vie feb 25 00:52:21 +0100 2011: On Fri, Feb 25, 2011 at 8:25 AM, jose.ali...@gmail.com jose.ali...@gmail.com wrote: Hi, On Tue, Feb 22, 2011 at 6:45 AM, Murray Cumming murr...@murrayc.com wrote: On Mon, 2011-02-21 at 21:57 +0100, Murray Cumming wrote: I'm trying to wrap GtkApplication for gtkmm but I can't really do that until I understand how it's meant to be used. In general, I find the documentation lacks overview and advice, partly because it's spread between GApplication and GtkApplication and mentions some concepts without explaining them first. So I have some questions. 1. Are we still meant to call gtk_init(argc, argv) when using GtkApplication, which takes argc/argv again via g_application_run(). Or is gtk_init() then superfluous? Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I don't understand why: http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3 2. How should we use GOptionContext to parse command line arguments from argc/argv when using GtkApplication. Is this the ideal way, using the command-line signal? http://git.gnome.org/browse/totem/tree/src/totem.c#n187 It seems a little long-winded. And more simply: 3. Will we recommend that all GTK+ applications generally use GtkApplication? 4. Do we believe that all (GTK+) applications should be single-instance applications? Just to point out an example, Evince does not use GtkApplication and it's not single instanced (there is one process per each document you see) and I don't think there are plans to make it single instanced. Right, however as I mentioned it would not hurt evince if it was a single instance, we would save on memory and gain in startup time for every document that evince is invoked for, without harming evince in any way. We think that robustness is more important than using more memory or taking a bit longer to start (I would like to see the numbers that proof that, since we changed from single process to multi-process nobody has filed a bug report about evince consuming more memory or being slower at startup). Evince depends on external libraries to render pdf, ps, etc. and it's easy to make those libs crash with buggy documents. So, unless GtkApplication allows us to keep our current multi-process model, still behaving as a single-instance app, we are not going to migrate. Furthermore using GtkApplication everywhere opens up the door for more sophisticated integration that could hypothetically happen in the future. - it would allow for system watchdogs to be implemented without any explicit cooperation on the part of the application for one, - it could serve to provide some basic system messaging for the desktop and applications, like updating the input method for all running applications, or even changing the desktop locale and retranslating messages (albeit runtime translation switching would of course require more api, but GtkLabel for instance could be given a translatable format and retranslate itself automatically whenever the desktop language changes...). I'm not saying that everybody should hurry up and do extra work they dont need to... however I do think having a unified GtkApplication api with as many apps using it as possible seems to be a step in the right direction (whether its the GNOME Shell that communicates with the GtkApplication, or MyCustomHandPhoneShell that uses it... having a well defined/unified api for this stuff seems like a good thing to have). Regards, -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _gtk_window_group_get_current_grab()
Excerpts from Jonh Wendell's message of sáb jun 05 20:35:52 +0200 2010:
Why does this symbol start with an underscore ? Can we use it in our
apps?
Context: I'm trying to get libview GSEAL compatible. I got into this:
if (window-group window-group-grabs) {
grabbed = GTK_WIDGET(window-group-grabs-data);
}
For window-group I have gtk_window_get_group().
gtk_window_get_group() always returns a valid pointer, use
gtk_window_has_group() instead (added in gtk+ 2.21.1)
For group-grabs I don't have anything, but the internal function
_gtk_window_group_get_current_grab() gives me exactly what I want.
So, can't we just get rid of that underscore and make this symbol
public? (Doing a recursive grep in gtk+ tree seems nobody is using this
'internal' symbol anyway)
Cheers,
Regards,
--
Carlos Garcia Campos
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462
signature.asc
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ print preview
El mar, 19-05-2009 a las 07:46 +0200, Sven Neumann escribió: Hi, On Mon, 2009-05-18 at 15:06 +0200, Carlos Garcia Campos wrote: I've realized that print preview doesn't work as I thought, and I'm bit confused. An application open the print dialog by using GtkPrintOperation, then the user clicks on preview and a pdf file is generated to be used by a previewer. Such a file is passed to evince together with the print settings needed to print the file. The print dialog is closed, so we need to be able to print the document from the previewer. I don't understand why the previewer should be used to print the document. You may be right that this is what the authors of the GTK+ print dialog intended, but it is certainly an odd concept. I find it very confusing that the Print dialog closes when I hit the Preview button. Wouldn't it be better if it stayed open so that I can make adjustments if the preview turns out wrong and hit the Print button when I am satisfied with the preview? Yes, I agree, this was already discussed in this list before[1], though. Leaving the print dialog open, would also allow to change again the print settings if you are not happy with the preview results or just want to try other settings. Current flow is quite annoying in such cases, since you have to close the previewer and start the whole process again. [1] http://mail.gnome.org/archives/gtk-devel-list/2006-June/msg00044.html -- Carlos Garcia Campos elkalm...@yahoo.es carlo...@gnome.org http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Warnings compiling with glib svn trunk
This change in glib: http://svn.gnome.org/viewvc/glib/trunk/glib/gi18n.h?r1=6713r2=6882 changes the prototype of _() returning now a const char *. This produces a lot of warnings in some programs. I've just noticed it compiling nautilus from svn trunk which seems to have the Werror flag active by default. is it an intentional change? or is it a compatibility issue that should be fixed in glib? -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Warnings compiling with glib svn trunk
El mié, 14-05-2008 a las 11:37 +0100, Emmanuele Bassi escribió: On Wed, 2008-05-14 at 12:25 +0200, Carlos Garcia Campos wrote: This change in glib: http://svn.gnome.org/viewvc/glib/trunk/glib/gi18n.h?r1=6713r2=6882 changes the prototype of _() returning now a const char *. This produces a lot of warnings in some programs. I've just noticed it compiling nautilus from svn trunk which seems to have the Werror flag active by default. _() always returned a const gchar*, be it when it was expanding to gettext() (which returns a const char*) or when it expanded to the string it contained. According to the gettext man page: #include libintl.h char * gettext (const char * msgid); applications keeping/modifying the string returned by _() around without copying it first have always been broken and should be fixed. yes, because the result is a a statically allocated string. ciao, Emmanuele. -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving Open with to the platform
El mar, 18-03-2008 a las 14:02 -0600, Federico Mena Quintero escribió: Hi, Right now, the Open with another application dialog lives in nautilus/libnautilus-private/nautilus-open-with-dialog.[ch]. This dialog uses the machinery in GIO's GAppInfo to figure out which apps can be used to open a file of a certain MIME-type. There's a long-standing annoyance in Firefox, where it implements open with by starting a file chooser in /usr/bin. Now, if you complain about the file chooser *right here* I will ignore your mail :) My point is that it would be nice if the open with GUI were available to all apps, not just Nautilus. We could do a few things: * Move nautilus-open-with-dialog.[ch] into GTK+. From a super-quick read of the code, this uses no Nautilus-only stuff except for some of libeel's convenience error dialogs, and some the MIME info changed signal. * Leave the dialog in place inside Nautilus, and provide a D-Bus service for the open with GUI. I'm 51% leaning towards this option, since then this would have a chance of working with a desktop-specific GUI, depending on your choice of desktop environment --- aside from promoting the use of D-Bus for this kind of stuff. Thoughts? I think it's something many applications would use, Evince uses always the default app when opening document attachments because we thought it wasn't worth to implement the whole open with stuff. I think it's better to move the dialog to GTK+, since nautilus might not be always running. Oh my god, this is a nice little project for the Summer of Code... it would involve figuring out the above, and also changing Firefox to use it :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Carlos Garcia Campos [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk Printing and evince
El mié, 19-07-2006 a las 08:20 -0400, Dominic Lachowicz escribió: Hi Carlos, In evince we have the document pages already rendered, so can I take the pixbuf of the page and create a cairo surface from it and use it in draw_page signal? I don't know if this is the right way to do it. Unless rendered at a high resolution, the output will probably look pretty ugly and be much larger than strictly necessary. Since poppler has a Cairo rendering backend and the GtkPrintContext pipeline is built around cairo, it'd probably be better to do something like this pseudo-code: cairo_t = gtk_print_context_get_cairo(context) for page in document.pages: poppler_page_render(page, cairo_t) Yes, I thought in something like this too, but it will only work with pdf and evince is not only a pdf viewer. Best, Dom Thanks, -- Carlos Garcia Campos (KaL) [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Evince preview mode
Hi, since gtk+ is using evince as an external printing previewer, I'm implementing a preview mode in evince, available through the command line (--preview). It's based on the ephy printing previewer where the menubar is hidden and the toolbar contains navigation items and a close button. Here is an screenshot: http://carlosgc.linups.org/files/evince-preview-mode.png Any other thing expected by a previewer? -- Carlos Garcia Campos (KaL) [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Evince preview mode
El mié, 07-06-2006 a las 09:13 -0400, Matthias Clasen escribió: On 6/7/06, Carlos Garcia Campos [EMAIL PROTECTED] wrote: Hi, since gtk+ is using evince as an external printing previewer, I'm implementing a preview mode in evince, available through the command line (--preview). It's based on the ephy printing previewer where the menubar is hidden and the toolbar contains navigation items and a close button. Here is an screenshot: http://carlosgc.linups.org/files/evince-preview-mode.png Any other thing expected by a previewer? A print button. hmm, when the user selects preview from the print dialog, the dialog disappears and evince is launched, so that if evince has a print button we should print the document directly without showing the print dialog again. I see several problems in this approach. First of all we can't know the print settings selected by the user from evince. And, should we close evince or keep it opened after clicking on print? Is it possible to print a pdf file with the new gtk+ api without showing any dialog? I think it's very confused. The best solution would be not to hide the dialog when the previewer is launched, so that once the user is happy with the results showed in evince, he simply clicks on print button. -- Carlos Garcia Campos (KaL) [EMAIL PROTECTED] [EMAIL PROTECTED] http://carlosgc.linups.org PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462 signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
