Re: ScrolledWindow, DrawingArea, and setting step-increment
Hmm. I used to have something using that, in one of the early tests, but there was either a critical performance problem, or something I couldn't do with it. Can that handle mark-and-copy, clickable URLs, and so on? Or possibly it's that you say thousands there; to me, thousands of lines is just barely getting started. My current session Mark copy and clickable urls are supported in the code example I sent you. About the thousands... I've not done specific benchmarks but I used to keep a scrollback of 5 lines in my old powerbook 800mhz without slowdowns. in Gypsum has barely started and I already have 50K lines; my RosMud session currently has 300K lines of scrollback; and I've noted as an unsolvable RosMud bug that it's unacceptably slow adding the 16,777,216th line to the buffer (because it does a naive I think that so many lines may be a problem for GtkTextBuffer, I mean, they are also a problem for an editor like vim :) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Question About Creating Composite Widget Template
I created a composite widget template with Glade, and now I am binding all the children in the composite widget template to private data members in my class. When I bind one particular member, box1, I get a segfault in gtk_widget_is_toplevel (widget=0x837b60) at gtkwidget.c:8474. If I don't bind box1, the application starts. Why would binding this child cause a segfault even though it is GtkWidget, defined in channel_list.ui? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Regarding theWin32/Visual C++ project completion items
Hello List, As people here might know, the Visual C++ 2008/2010 projects to build the GNOME parts of the GTK+ and Clutter stack are currently using autotools to fill in the source file listings during 'make dist', which was mostly doing the job for getting the project files to be kept up-to-date for building these libraries on Windows, which is an idea that was initiated by Tor Lillqvist when he started providing such mechanism to provide Visual Studio build support aimed to ease maintenance of such files. However, as time progresses, it turns out that there are some disadvantages with this approach: -It adds significant bits to the various Makefile.am's. -It is not easy for people using a GIT checkout to build the libraries under Windows/Visual Studio directly (one must 'make dist' tarball from a Linux system in order to get the necessary project files and source files using autogen.sh), hence items from others have been used to facilitate this kind of thing for GLib [1] -There needs to be tailored filter lists to get the correct sources in the project files, especially as the release tarballs are generated on Linux, meaning the source files that are meant for Linux (not Windows) will be picked up for the project files if those filters are not in place, and these filters can be out-of sync from time-to-time -Possibly some other issues with this as well. I am, therefore, thinking about using sets of Python 2/3 scripts (credits to Shixin Zeng for the original idea[1]) to facilitate the same functionality to complete the various Visual Studio Project (and also NMake Makefiles, where applicable), which has the following advantages compared to the current approach that I've mentioned earlier in this e-mail-a proposal for this can be found in [2]: -It can be invoked rather easily during 'make dist' by calling the Python script with the appropriate parameters -It is split in 2 parts for GLib, for one universal part (msvcfiles.py) can be used for various projects while the project-specfic parts can be in another Python script (glib_msvc_files.py) , which includes the needed items from the msvcfiles.py and creates the necessary project files for the specific project/ -It can also be invoked from a standard Windows cmd.exe prompt using Python, so that the necessary project files and/or NMake Makefiles can be created to be used on the spot. -The Python scripts will read from the various Makefile.am's using Python regex functionality, so the necessary build conditions (such as OS_WIN32) can be set to acquire the necessary source files for the msvc project files/NMake Makefiles, so filtering off the Linux source files can be significantly reduced, if not significantly eliminated. This will simplify maintenance, at least on my side, as I am certainly not an autotools expert. -It is already extended to make the listing of headers to install after building the various libraries, as the list of headers change from time in a development cycle, also to simplify maintenance on my part. The key purpose in this venture is to make it easier for other people interested in using/developing the GTK+/Clutter (and its dependent libraries/items) stack to contribute to their development and maintenance on Windows, as I am inclined to believe people developing on Windows are more leaned towards using MSVC over MinGW (no offense intended here, even as I do not use MinGW most of the time, I still believe it (and its derived projects) is a formidable project). I just wanted to hear from people here about what they think about this, especially: -Whether this is a viable approach-i.e. whether Python 2/3 is readily available on the Linux systems which people use to generate dist tarballs (I am not too acquainted with the Python situation on Linux, but I am inclined to believe that it is bundled with most Linux distros at least), and whether people think this change is useful as a whole, so that I can see whether this is something I want to really venture into for the other parts of the GTK+/Clutter stack -Any other comments on this approach. [1]: Please see build/win32/setup.py by Shixin Zeng in the GLib GIT checkout for an example for this. [2]: Please see attachment 259242 (Add NMake Makefiles to build the GLib unit tests (take ii, automation added)) in Bug 711047 for a proposal. This contains the parts necessary for the msvc project files and property sheets, but the patch does not yet integrate completion of the project files using those scripts (however, it can be done quite easily by adding something like: glib.vcproj: $(PYTHON) $(top_srcdir)/build/glib_msvc_files.py -t vs9 in build/win32/vs9/Makefile.am for example Thanks for the time, with blessings! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Regarding theWin32/Visual C++ project completion items
On Wed, Nov 13, 2013 at 12:24 PM, Colin Walters walt...@verbum.org wrote: On Wed, 2013-11-13 at 17:10 +0800, fanc...@yahoo.com.tw wrote: -The Python scripts will read from the various Makefile.am's using Python regex functionality, My main concern here is about what kinds of additional restrictions this might add to the Makefile.am files we are using. For example, would this script support nested conditionals like: if BUILDOPT_FOO if BUILDOPT_BAR blah_SOURCES += foo-and-bar.c endif endif etc. Basically there will be an ongoing cost of having two independent programs parsing the same Makefile.am files - we'll have to identify a subset that works for both. I can only speak for my script that is refered to by Fan. It doesn't understand Makefile.am at all. All it does is looking for some strings of interest using regex. The programmer needs to parse the Makefile.am first and finds out what strings the script needs to look for, and all that logic is hardcoded in the script. If the structure of the Makefile.am changes, the script needs to be updated correspondingly. I don't think it's worth making it a makefile.am parser, as the whole script was written in a couple of hours, and writing a makefile.am parser itself would take much more time than that. -Whether this is a viable approach-i.e. whether Python 2/3 is readily available on the Linux systems which people use to generate dist tarballs Yes, I think that's fine. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list Best Regards Shixin Zeng ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RFC: Popovers
Hey all, TL;DR: API for popovers is in the popovers branch, adds GtkWindow low-level API, and a GtkPopover widget. I took some time in refurbishing GtkBubbleWindow so it'd be more generally useful. In principle it could be desirable to have popovers not tied to the usual menu grab semantics, and give some more freedom to regulate its visibility and behavior. The work is at: https://git.gnome.org/browse/gtk+/log?h=popovers Playing with this kind of free behavior I realized that using a GDK_WINDOW_TEMP window is not quite ideal, if a toplevel can be moved around or unfocused with a popover on it being shown, you get stacking weirdness, and bursts of sync calls happen to translate things to root coordinates. So I've been playing with implementing popovers as GDK_WINDOW_CHILD windows on the closest GtkWindow, while this seeminly brings some kind of API overlap with GtkOverlay, I think it could be more widely useful than just the pointy bubble windows, but also tooltips, text selection handles, or the treeview search entry, which aren't as excusable popup windows. So far I could find these advantages in using popovers: * Results in less sync calls to translate things to root coordinates: This is specially taxing on text handles, as those stay when a textview scrolls, causing frequent translation of coordinates. OTOH there's less visual lagging too as gtk_window_move() might not be honored immediately. * Works right away without grabs nor event forwarding, the textview does some event forwarding hacks in order to ensure the search entry gets key events, as a keyboard grab is not set in that case. More generally, not using GDK_WINDOW_TEMP makes grabs much less of a necessity, and if a modal behavior is desired, it's just a gtk_grab_add() away. The only wart I actually see is that popovers implemented this way rely on having enough space on the toplevel window, GtkWindow of course ensures that those don't fall out of coordinates if there's overflowing space at the other side, but it won't attempt to expand the window if there's a lack of width or height. This should be rarely a problem on most sane UIs though, I could just think of the empathy contact tooltips of the core gnome apps that could present a problem with this. But so far, in the branch only GtkPopover uses the GtkWindow popover low-level API, and there's a gtk3-demo popover demo. Does this generally sound like an alright direction? Cheers, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Popovers
Hi again, 2 more notes, * The changes on the branch look much better with he patch at http://pastebin.com/70q9NcFh , due to the class name change. * Jasper on IRC pointed out that on wayland subsurfaces are a very good fit for this, and he's indeed right. I do think an API like the proposed one has a better path forward when GDK gets to expose subsurfaces, compared to the popover as GtkWindow subclass one. Cheers, Carlos On mié, 2013-11-13 at 20:58 +0100, Carlos Garnacho wrote: Hey all, TL;DR: API for popovers is in the popovers branch, adds GtkWindow low-level API, and a GtkPopover widget. I took some time in refurbishing GtkBubbleWindow so it'd be more generally useful. In principle it could be desirable to have popovers not tied to the usual menu grab semantics, and give some more freedom to regulate its visibility and behavior. The work is at: https://git.gnome.org/browse/gtk+/log?h=popovers Playing with this kind of free behavior I realized that using a GDK_WINDOW_TEMP window is not quite ideal, if a toplevel can be moved around or unfocused with a popover on it being shown, you get stacking weirdness, and bursts of sync calls happen to translate things to root coordinates. So I've been playing with implementing popovers as GDK_WINDOW_CHILD windows on the closest GtkWindow, while this seeminly brings some kind of API overlap with GtkOverlay, I think it could be more widely useful than just the pointy bubble windows, but also tooltips, text selection handles, or the treeview search entry, which aren't as excusable popup windows. So far I could find these advantages in using popovers: * Results in less sync calls to translate things to root coordinates: This is specially taxing on text handles, as those stay when a textview scrolls, causing frequent translation of coordinates. OTOH there's less visual lagging too as gtk_window_move() might not be honored immediately. * Works right away without grabs nor event forwarding, the textview does some event forwarding hacks in order to ensure the search entry gets key events, as a keyboard grab is not set in that case. More generally, not using GDK_WINDOW_TEMP makes grabs much less of a necessity, and if a modal behavior is desired, it's just a gtk_grab_add() away. The only wart I actually see is that popovers implemented this way rely on having enough space on the toplevel window, GtkWindow of course ensures that those don't fall out of coordinates if there's overflowing space at the other side, but it won't attempt to expand the window if there's a lack of width or height. This should be rarely a problem on most sane UIs though, I could just think of the empathy contact tooltips of the core gnome apps that could present a problem with this. But so far, in the branch only GtkPopover uses the GtkWindow popover low-level API, and there's a gtk3-demo popover demo. Does this generally sound like an alright direction? Cheers, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Regarding theWin32/Visual C++ project completion items
Hi, Speaking as a consumer of the MSVC project files, is it too much to ask for contributors to maintain the project files statically and update them whenever they update the makefiles? There is no need to do this in VS or even Windows; the vcxproj file is easy to maintain via a text editor. It seems to me, Fan, that you're suggesting a (perhaps limited) autotools simulator in Python to convert the original makefile into a MSVC project file? It sounds like it would be very error-prone and require a lot of special-casing for individual projects (as Shixin's e-mail seems to suggest also). Regards, Arnav On Wed, Nov 13, 2013 at 10:33 AM, Shixin Zeng zeng.shi...@gmail.com wrote: On Wed, Nov 13, 2013 at 12:24 PM, Colin Walters walt...@verbum.org wrote: On Wed, 2013-11-13 at 17:10 +0800, fanc...@yahoo.com.tw wrote: -The Python scripts will read from the various Makefile.am's using Python regex functionality, My main concern here is about what kinds of additional restrictions this might add to the Makefile.am files we are using. For example, would this script support nested conditionals like: if BUILDOPT_FOO if BUILDOPT_BAR blah_SOURCES += foo-and-bar.c endif endif etc. Basically there will be an ongoing cost of having two independent programs parsing the same Makefile.am files - we'll have to identify a subset that works for both. I can only speak for my script that is refered to by Fan. It doesn't understand Makefile.am at all. All it does is looking for some strings of interest using regex. The programmer needs to parse the Makefile.am first and finds out what strings the script needs to look for, and all that logic is hardcoded in the script. If the structure of the Makefile.am changes, the script needs to be updated correspondingly. I don't think it's worth making it a makefile.am parser, as the whole script was written in a couple of hours, and writing a makefile.am parser itself would take much more time than that. -Whether this is a viable approach-i.e. whether Python 2/3 is readily available on the Linux systems which people use to generate dist tarballs Yes, I think that's fine. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list Best Regards Shixin Zeng ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Regarding theWin32/Visual C++ project completion items
於 2013/11/14 01:24, Colin Walters 提到:
My main concern here is about what kinds of additional restrictions this
might add to the Makefile.am files we are using. For example, would
this script support nested conditionals like:
if BUILDOPT_FOO
if BUILDOPT_BAR
blah_SOURCES += foo-and-bar.c
endif
endif
In the form of the patch that I posted in bug 711047 (attachment
259242), this is supported. I have enhanced Shixin's scripts a bit to
support this.
I have quickly tested this under Python 2.7.5 in Windows using this
patch by updating the line in glib_msvc_files.py:
gio_test_filters_conds = {'OS_WIN32': True}
-to-
gio_test_filters_conds = {'OS_WIN32': True, 'OS_UNIX': True,
'HAVE_DBUS_DAEMON': True, 'HAVE_DBUS1': True}
which indeed added the *NIX and d-bus test programs into the list of
programs to build, for example (it's obviously not fully buildable for
MSVC, but this is to verify things :) ).
I don't think this should impose any restrictions on the Makefile.am's
that are being used at all.
etc. Basically there will be an ongoing cost of having two independent
programs parsing the same Makefile.am files - we'll have to identify a
subset that works for both.
As Shixin mentioned, this basically reads the various Makefile.am's to
get the strings (i.e. source files) based on the conditions that was
passed in and to fill them into the MSVC files. These Python 2/3
scripts do nothing more than that.
I used msvcfiles.py to contain most of the functions that would be
shared between projects, and glib_msvc_files.py for items that are
specific to the GLib package, for references.
-Whether this is a viable approach-i.e. whether Python 2/3 is readily
available on the Linux systems which people use to generate dist
tarballs
Yes, I think that's fine.
Thanks! I really appreciate this piece of info.
List: are there other views about the Python situation on the Linux systems?
With blessings, thank you!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Regarding theWin32/Visual C++ project completion items
Hello Arnavion, Speaking as a consumer of the MSVC project files, is it too much to ask for contributors to maintain the project files statically and update them whenever they update the makefiles? There is no need to do this in VS or even Windows; the vcxproj file is easy to maintain via a text editor. As the maintainer of the MSVC project files, these are some reasons why I (and previously Tor) wanted to keep the Project Files done in a dynamic way: -Sources get added/removed/changed (i.e. renamed/moved/split) every now and then, and updates to Makefile.am may slip pass me until after a release. For updating the MSVC projects for one project with a text editor (BTW this is what I use though) may not seem much, but currently I maintain the MSVC projects for GLib, ATK, Pango, GDK-Pixbuf, GTK+ (2.x 3.x), Cogl, JSON-GLib, Clutter and GObject-Introspection, and co-maintaining the ones for glibmm, pangomm, atkmm and gtkmm, and the source listings need to be updated for both vs9 and vs10, so doing it this way will ease the process significantly. Note that the MSVC projects for the -mm packages are currently done statically, and I think if it is okay with the people there, I think it would be best to make it done in a way like what is being proposed (or even what is now done). -The property sheets used to install the headers are currently done statically, but like the last point, it would be easier to maintain in the long run by doing them dynamically -I would also like to have more time to invest in the continual improvement/maintenance of these GNOME libs (and possibly other GNOME libs/apps) on Windows (and possibly attract more Windows devs, as I've mentioned in my original post) -Having the project files done dynamically is also the preferred way to do this for the maintainers, at least for the GTK+/Clutter stack. It seems to me, Fan, that you're suggesting a (perhaps limited) autotools simulator in Python to convert the original makefile into a MSVC project file? It sounds like it would be very error-prone and require a lot of special-casing for individual projects (as Shixin's e-mail seems to suggest also). No, this is not an autotools simulator as Shixin mentioned. This is mainly meant to get the strings (i.e. source files listings) with the appropriate conditions to put into the MSVC files. For references, you can take a look at my patch in bug 711047 (attachment 259242, Add NMake Makefiles to build the GLib unit tests (take ii, automation added)) as an example... I've isolated the project-neutral parts from the GLib-specific parts, as far as possible into msvcfiles.py and glib_msvc_files.py respectively. So I would, after checking whether the caller calls glib_msvc_files.py correctly, set up the strings to look for and the special cases (e.g. Win32-specific sources, ...) in glib_msvc_files.py, to read the correct Makefile.am's to get the correct sources/files to be put into the individual MSVC project files/NMake Makefiles. You are right that I have to be careful about the filters and cases to check, but it's not that much of an issue as changes in the cases occur far less often than the addition/removal/changes to the sources themselves. Hope this explains this a bit. With blessings. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Regarding theWin32/Visual C++ project completion items
-Sources get added/removed/changed (i.e. renamed/moved/split) every now and then, and updates to Makefile.am may slip pass me until after a release. For updating the MSVC projects for one project with a text editor (BTW this is what I use though) may not seem much, but currently I maintain the MSVC projects for GLib, ATK, Pango, GDK-Pixbuf, GTK+ (2.x 3.x), Cogl, JSON-GLib, Clutter and GObject-Introspection, and co-maintaining the ones for glibmm, pangomm, atkmm and gtkmm, and the source listings need to be updated for both vs9 and vs10, so doing it this way will ease the process significantly. Note that the MSVC projects for the -mm packages are currently done statically, and I think if it is okay with the people there, I think it would be best to make it done in a way like what is being proposed (or even what is now done). Well what I meant was that rather than have you maintain them, the people who modify the makefiles could do it. If you find your way is maintainable, sure, go for it. I'm just surprised that it has been one person's job to maintain project files rather than everyone's. As I said earlier, why not simply require all updates to the makefiles be mirrored in the vcxproj files too? Is that unenforcable? -Arnav On Wed, Nov 13, 2013 at 8:30 PM, Fan Chun-wei fanc...@yahoo.com.tw wrote: Hello Arnavion, Speaking as a consumer of the MSVC project files, is it too much to ask for contributors to maintain the project files statically and update them whenever they update the makefiles? There is no need to do this in VS or even Windows; the vcxproj file is easy to maintain via a text editor. As the maintainer of the MSVC project files, these are some reasons why I (and previously Tor) wanted to keep the Project Files done in a dynamic way: -Sources get added/removed/changed (i.e. renamed/moved/split) every now and then, and updates to Makefile.am may slip pass me until after a release. For updating the MSVC projects for one project with a text editor (BTW this is what I use though) may not seem much, but currently I maintain the MSVC projects for GLib, ATK, Pango, GDK-Pixbuf, GTK+ (2.x 3.x), Cogl, JSON-GLib, Clutter and GObject-Introspection, and co-maintaining the ones for glibmm, pangomm, atkmm and gtkmm, and the source listings need to be updated for both vs9 and vs10, so doing it this way will ease the process significantly. Note that the MSVC projects for the -mm packages are currently done statically, and I think if it is okay with the people there, I think it would be best to make it done in a way like what is being proposed (or even what is now done). -The property sheets used to install the headers are currently done statically, but like the last point, it would be easier to maintain in the long run by doing them dynamically -I would also like to have more time to invest in the continual improvement/maintenance of these GNOME libs (and possibly other GNOME libs/apps) on Windows (and possibly attract more Windows devs, as I've mentioned in my original post) -Having the project files done dynamically is also the preferred way to do this for the maintainers, at least for the GTK+/Clutter stack. It seems to me, Fan, that you're suggesting a (perhaps limited) autotools simulator in Python to convert the original makefile into a MSVC project file? It sounds like it would be very error-prone and require a lot of special-casing for individual projects (as Shixin's e-mail seems to suggest also). No, this is not an autotools simulator as Shixin mentioned. This is mainly meant to get the strings (i.e. source files listings) with the appropriate conditions to put into the MSVC files. For references, you can take a look at my patch in bug 711047 (attachment 259242, Add NMake Makefiles to build the GLib unit tests (take ii, automation added)) as an example... I've isolated the project-neutral parts from the GLib-specific parts, as far as possible into msvcfiles.py and glib_msvc_files.py respectively. So I would, after checking whether the caller calls glib_msvc_files.py correctly, set up the strings to look for and the special cases (e.g. Win32-specific sources, ...) in glib_msvc_files.py, to read the correct Makefile.am's to get the correct sources/files to be put into the individual MSVC project files/NMake Makefiles. You are right that I have to be careful about the filters and cases to check, but it's not that much of an issue as changes in the cases occur far less often than the addition/removal/changes to the sources themselves. Hope this explains this a bit. With blessings. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
