Re: Volunteer
Hi Matthias, For a start, I'll pick up your first suggestion. For your nested scrolling use case, I think it a good start would be a somewhat convincing testcase. In my experience nested scrolling is almost always a source of frustration and best avoided... A test case I was thinking of was to implement an image gallery similar to those on mobile devices: Swiping left and right scrolls between images, pinching would let you zoom, and when you've zoomed such that the image is larger than the area, just dragging lets you scroll the image, until you've reached a boundary, after which you'd start dragging the neighboring image in. I'm actually not even sure if a scrolled windows would be the best way to implement this. Some new features would have to be added anyway: Support for paging (ie. bounce back to a page boundary after the drag is released), support for zooming, and probably an option to hide scrollbars. A problem we would have with paging would be that the start of a page would change when the scrolled window gets resized, and to accomodate to that we would need to automatically scroll the widget while it's being resized. Because page boundaries farther away from the origin might then move much faster than the amount the size of the scrolled window changed, this might give very weird results. In the case of the image gallery, this wouldn't be a problem, because you would always change the size of the children to match the size of the visible area of the outer scrolled window. An option would of course be to use a GtkStack instead, and add support for swiping between pages (as you suggested). Personally, I'd like it if it'd still behaved a bit like a paging scrolled window, ie: it starts scrolling as soon as you start dragging, and bounces to the nearest page when you release the touch (probably taking velocity into account, so a very short but fast swipe will move to the next page). But still, I think that to implement this, we might still need functionality which lets widgets propagate only a part of a drag gesture to its parent widget. Regards, Lieven On Wed, Jun 4, 2014 at 11:13 PM, Matthias Clasen matthias.cla...@gmail.com wrote: Hey Lieven, great that you are interested in helping out ! I'm sure you'll find something interesting to work on. Here's a few ideas: - pick any widget that is currently still using a button press event handler, and convert it to using event controllers instead - add support for switching pages by swipe gestures in GtkStack (probably depending on the transition) - investigate using swipe-from-the-edge for bringing up controls in fullscreen mode - choose any application that could benefit from touch support, and try to implement it using the current GTK+ gesture API (one example might be swipes to show/hide the sidebar in gnome-weather)/ For your nested scrolling use case, I think it a good start would be a somewhat convincing testcase. In my experience nested scrolling is almost always a source of frustration and best avoided... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Volunteer
Hey Lieven, On Wed, Jun 4, 2014 at 7:32 PM, Lieven van der Heide lievenvanderhe...@gmail.com wrote: Hi, I'd like to volunteer to help with gtk development, preferably with improving touch support. It is great that you want to help! There's being some activity around, with the recently merged gestures branch. Some low hanging fruits would indeed be making older widgets use this, or (possibly more entertaining) possibility is finding places where gestures or touch-specific UI could be handy (eg. on otherwise non interactable widgets). It would be good if you'd compile gtk+ master and got familiarized with the changes there by reading docs/code. I've already submitted the kinetic scrolling improvement fixes not too long ago (still waiting for it to be in git though), It was pushed this evening :), nice work! so I know the code a bit. Are there any open tickets I could pick up? There are plenty of improvements I can think of, but I guess it's better to stick to the current roadmap. One useful bugzilla query might be: https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;component=Class%3A%20GdkDevice;component=Class%3A%20GtkGesture;product=gtk%2B Althought there's not many opened bugs related to touch currently as you can see. It would be great if you could hang out in #gtk+ and #gnome-design, that's where most of the activity around GTK+/touch goes on. One thing I really think gtk should need though, and which I'd like to help with is this: https://bugzilla.gnome.org/show_bug.cgi?id=731221 but I realize that it's quite a big change, so I guess it first needs to be decided if and how we're going to do it. I have to agree with Matthias that it would be probably better if you found tangible/compelling usecases before embarking on this, you realize well that it's not a small change (not only event management wise, but very possibly to GtkAdjustment/GtkScrollable API). IMHO, the only UIs that can't do without scrollable-within-scrollable are webbrowsers, and GTK+ luckily doesn't have to cater for that case. Cheers, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Volunteer
Hi, I'd like to volunteer to help with gtk development, preferably with improving touch support. I've already submitted the kinetic scrolling improvement fixes not too long ago (still waiting for it to be in git though), so I know the code a bit. Are there any open tickets I could pick up? There are plenty of improvements I can think of, but I guess it's better to stick to the current roadmap. One thing I really think gtk should need though, and which I'd like to help with is this: https://bugzilla.gnome.org/show_bug.cgi?id=731221 but I realize that it's quite a big change, so I guess it first needs to be decided if and how we're going to do it. Regards, Lieven. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Possible volunteer for website
Felix Rabe (public) wrote: Hi, Hi, I've read the recent thread on the subject and would be interested in helping out with the website. I can't dedicate much time to it before end of June though. I already sent short private notes to Tim Janik and Martyn Russell. Yes, and thank you for your support, it is much appreciated. I have not looked at many web CMS yet. I worked with Wordpress lately and was not comfortable. I'm also worried about PHP's bad security publicity here and there. I used PHP earlier, at the time version 4 came out, and forgot most of it. I wonder why the Ubuntu website was migrated [1] to Drupal as opposed to Plone and am looking forward to the author's follow-up article. I have used both and I think it is obvious from just using it, let alone the administrative advantages/disadvantages. I also think that Mikael outlined exactly why Drupal would be the best choice for gtk.org. I currently use Cheetah [2] for a total website revamp [3, 4] and like its simplicity and Python integration. I am not sure we really need that with gtk.org at this point. At the moment it is a clear case (x)html/css update of the site and general clean up. Also, after speaking with Tim further, we have decided to progress with the site update without a CMS for the time being since we don't have the hardware for it and the wait is likely to be several months. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Possible volunteer for website
Hi, ( Sorry Martyn for sending that message twice - do you have a hint how to tell Thunderbird to reply to gtk-devel-list, or do you change To: manually every time you reply to the list? ) Martyn Russell wrote: I have used both and I think it is obvious from just using it, let alone the administrative advantages/disadvantages. I also think that Mikael outlined exactly why Drupal would be the best choice for gtk.org. I'll give my comments where I can and/but accept the final decision. I currently use Cheetah [2] for a total website revamp [3, 4] and like its simplicity and Python integration. I am not sure we really need that with gtk.org at this point. At the moment it is a clear case (x)html/css update of the site and general clean up. As I know XHTML and CSS, I guess my starting point would be to check out gtk-web, have a look at it and come back into the migration discussion, as currently I'm just not qualified to give any comment, but I'm sure to be able to lend a hand. Also, after speaking with Tim further, we have decided to progress with the site update without a CMS for the time being since we don't have the hardware for it and the wait is likely to be several months. I use Cheetah to generate static pages and think that performance should not be wasted on dynamic generation where avoidable. As a sidenote, I learned to use Rsync a short while ago thanks to the great advice on the textdrive.com help pages - it solves many of the hassles I had earlier with website uploads and backups. My home directory contains .rsync-exec-usb-hd.sh and similar scripts, together with .rsync-filter-*.txt files. Well, but I better have a look at existing GTK web practices before making tons of that sort of comments :) Greetings, Felix Rabe ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Possible volunteer for website
Hi, I've read the recent thread on the subject and would be interested in helping out with the website. I can't dedicate much time to it before end of June though. I already sent short private notes to Tim Janik and Martyn Russell. Short intro (safely skip this paragraph): I mostly program Python nowadays when not studying Theology, but know (X)HTML and CSS and more that might help the website work. I'm 22 with programming experience since 8. I generally prefer text-based formats and choose them over WYSIWYG equivalents anytime, unless the latter really helps me get the job done quicker. I also like simplicity in UI and web design - that's maybe why I use GNOME. I have not looked at many web CMS yet. I worked with Wordpress lately and was not comfortable. I'm also worried about PHP's bad security publicity here and there. I used PHP earlier, at the time version 4 came out, and forgot most of it. I wonder why the Ubuntu website was migrated [1] to Drupal as opposed to Plone and am looking forward to the author's follow-up article. I currently use Cheetah [2] for a total website revamp [3, 4] and like its simplicity and Python integration. Greetings, Felix Rabe ( www.felixrabe.net ) [1] http://www.bearfruit.org/blog/2007/03/14/the-new-ubuntu-website/ [2] http://www.cheetahtemplate.org/ [3] http://www.wohnheim-obstgarten.ch/ (what I'm starting from) [4] http://felixrabe.textdriven.com/whog/Release+1/html/ (WIP) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ Volunteer tasks
On Thu, 19 Apr 2007, Clemens Eisserer wrote: My idea would be to make backbuffer-handling more flexible: - If several x-windows are repainted do not acquire a backbuffer for every sub-window, instead acquire one (for the largest repainted are) and share it. this is already the case, further refinements are handled in this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=169544 lg Clemens --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ Volunteer tasks
Hi, Very happy to see something is happening on that side :-) I personally dislike GTK a bit ... but keeping in mind its improntance for Linux in general I am really happy that things are ongoing to make contributions easier. I am also happy that at least the statement has been accepted that GTK has some weaks (as any other software) and that they need to be adressed somehow ... to be honest I even wondered to read this ;) My idea would be to make backbuffer-handling more flexible: - If several x-windows are repainted do not acquire a backbuffer for every sub-window, instead acquire one (for the largest repainted are) and share it. - Modularize backbuffer-handling in general, to allow the distributor to select wether backbuffers should be kept, re-allocated after every repaint or destroyed after some time of inactivity. Well if there's interrest on that I could try to work on it in summer, if not ... no problem. lg Clemens 2007/4/13, Tim Janik [EMAIL PROTECTED]: Hi All. The State of the Gtk+ Maintenance email outlined several tasks that can be accomplished by non-senior Gtk+ developers: http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00074.html Since that email was sent out, many people have asked for concrete advice on how they can help the Gtk+ project. Unfortunately, we do not currently have any formal setup or even semi- structured process to utilize such voluntary offers. So, one suggestion that was raised was to start a voluntary task list, where people can sign up for individual tasks to help Gtk+ project maintenance and development. I found this particular suggestion to be a very good idea and would like to suggest that we: 1) Create a openly-editable wiki page with a Gtk+ project task list; note that this is different from the Gtk+ Love Bug List started by Xan: http://live.gnome.org/GtkLove because it's about non-bug tasks that can help the project. I've started construction of this at: http://live.gnome.org/GtkTasks 2) The tasks should be signed up for by individual volunteers (or maybe multiple volunteers as needed) who want to work on particular items quasi regularly. People should also remove their entries if they have to step back from tasks at some point, so others know which tasks are up for grabs. 3) The actual task list is subject to change as we identify needs of the project. Below i've collected initial ideas that seem suitable for Gtk+ at this point and that borrow positions from other projects. 4) Embrace new contributors by making it easy for them to gain commit rights for non critical sections (gtk-web, doc) and for code changes as long as there's still some core developer review (e.g. by IRC requests + pastebin patch sighting). Here comes the tentative initial task list, I'm open for any comments/critics to improve or adapt this: Permanennt Tasks: +--+--+ | Gtk+ Project Task Description| Person in charge [*] | +==+==+ | Bug testing triaging; [1] | | +--+--+ | Patch testing committing; [2] | | +--+--+ | Patch/bug monitoring filing; [3] | | +--+--+ | Website (*content*) maintainer; [4] | | +--+--+ | FAQ maintainer; [5] | | +--+--+ | Spam handling on mailing lists | [EMAIL PROTECTED] | +--+--+ Transient Tasks: +--+--+ | Gtk+ Project Task Description| Person in charge [*] | +==+==+ | Canvas evaluation moderator; [6] | | +--+--+ Resources: Website: http://www.gtk.org/ IRC Channel: #gtk+ on GimpNet FAQ: http://www.gtk.org/faq/ Tutorial:http://www.gtk.org/tutorial/ API docs:http://developer.gnome.org/doc/API/ Lists: http://mail.gnome.org/archives/gtk-devel-list/ http://mail.gnome.org/archives/gtk-app-devel-list/ http://mail.gnome.org/archives/gtk-list/ GLib Bugs:
Gtk+ Volunteer tasks
[Reply-To: set for [EMAIL PROTECTED] Hi All. The State of the Gtk+ Maintenance email outlined several tasks that can be accomplished by non-senior Gtk+ developers: http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00074.html Since that email was sent out, many people have asked for concrete advice on how they can help the Gtk+ project. Unfortunately, we do not currently have any formal setup or even semi- structured process to utilize such voluntary offers. So, one suggestion that was raised was to start a voluntary task list, where people can sign up for individual tasks to help Gtk+ project maintenance and development. I found this particular suggestion to be a very good idea and would like to suggest that we: 1) Create a openly-editable wiki page with a Gtk+ project task list; note that this is different from the Gtk+ Love Bug List started by Xan: http://live.gnome.org/GtkLove because it's about non-bug tasks that can help the project. I've started construction of this at: http://live.gnome.org/GtkTasks 2) The tasks should be signed up for by individual volunteers (or maybe multiple volunteers as needed) who want to work on particular items quasi regularly. People should also remove their entries if they have to step back from tasks at some point, so others know which tasks are up for grabs. 3) The actual task list is subject to change as we identify needs of the project. Below i've collected initial ideas that seem suitable for Gtk+ at this point and that borrow positions from other projects. 4) Embrace new contributors by making it easy for them to gain commit rights for non critical sections (gtk-web, doc) and for code changes as long as there's still some core developer review (e.g. by IRC requests + pastebin patch sighting). Here comes the tentative initial task list, I'm open for any comments/critics to improve or adapt this: Permanennt Tasks: +--+--+ | Gtk+ Project Task Description| Person in charge [*] | +==+==+ | Bug testing triaging; [1] | | +--+--+ | Patch testing committing; [2] | | +--+--+ | Patch/bug monitoring filing; [3] | | +--+--+ | Website (*content*) maintainer; [4] | | +--+--+ | FAQ maintainer; [5] | | +--+--+ | Spam handling on mailing lists | [EMAIL PROTECTED] | +--+--+ Transient Tasks: +--+--+ | Gtk+ Project Task Description| Person in charge [*] | +==+==+ | Canvas evaluation moderator; [6] | | +--+--+ Resources: Website: http://www.gtk.org/ IRC Channel: #gtk+ on GimpNet FAQ: http://www.gtk.org/faq/ Tutorial:http://www.gtk.org/tutorial/ API docs:http://developer.gnome.org/doc/API/ Lists: http://mail.gnome.org/archives/gtk-devel-list/ http://mail.gnome.org/archives/gtk-app-devel-list/ http://mail.gnome.org/archives/gtk-list/ GLib Bugs: http://bugzilla.gnome.org/buglist.cgi?query=product:glib Gtk+ Bugs: http://bugzilla.gnome.org/buglist.cgi?query=product:gtk%2B [*] Please sign up for a task by adding your real name and a working email address. Multiple people may sign up for a task, they should communicate with each other to avoid duplication of effort however. [1] Bugs regularly need to be sorted out and patches filed therein need to be tested and possibly adapted. A detailed description is given here: http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html (Re: Supporting Gtk+ Maintenance) [2] Patch snippets that get pasted/submitted via email/irc/etc. and that core developers can approve off head still need to be actually applied, compiled, tested with our test suite, be committed and potentially back- merged onto other branches. Someone signing up for this should have reasonable C knowledge, hang out on #gtk+ and be frequently reachable via email.
Gtk+ Volunteer tasks
Hi All. The State of the Gtk+ Maintenance email outlined several tasks that can be accomplished by non-senior Gtk+ developers: http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00074.html Since that email was sent out, many people have asked for concrete advice on how they can help the Gtk+ project. Unfortunately, we do not currently have any formal setup or even semi- structured process to utilize such voluntary offers. So, one suggestion that was raised was to start a voluntary task list, where people can sign up for individual tasks to help Gtk+ project maintenance and development. I found this particular suggestion to be a very good idea and would like to suggest that we: 1) Create a openly-editable wiki page with a Gtk+ project task list; note that this is different from the Gtk+ Love Bug List started by Xan: http://live.gnome.org/GtkLove because it's about non-bug tasks that can help the project. I've started construction of this at: http://live.gnome.org/GtkTasks 2) The tasks should be signed up for by individual volunteers (or maybe multiple volunteers as needed) who want to work on particular items quasi regularly. People should also remove their entries if they have to step back from tasks at some point, so others know which tasks are up for grabs. 3) The actual task list is subject to change as we identify needs of the project. Below i've collected initial ideas that seem suitable for Gtk+ at this point and that borrow positions from other projects. 4) Embrace new contributors by making it easy for them to gain commit rights for non critical sections (gtk-web, doc) and for code changes as long as there's still some core developer review (e.g. by IRC requests + pastebin patch sighting). Here comes the tentative initial task list, I'm open for any comments/critics to improve or adapt this: Permanennt Tasks: +--+--+ | Gtk+ Project Task Description| Person in charge [*] | +==+==+ | Bug testing triaging; [1] | | +--+--+ | Patch testing committing; [2] | | +--+--+ | Patch/bug monitoring filing; [3] | | +--+--+ | Website (*content*) maintainer; [4] | | +--+--+ | FAQ maintainer; [5] | | +--+--+ | Spam handling on mailing lists | [EMAIL PROTECTED] | +--+--+ Transient Tasks: +--+--+ | Gtk+ Project Task Description| Person in charge [*] | +==+==+ | Canvas evaluation moderator; [6] | | +--+--+ Resources: Website: http://www.gtk.org/ IRC Channel: #gtk+ on GimpNet FAQ: http://www.gtk.org/faq/ Tutorial:http://www.gtk.org/tutorial/ API docs:http://developer.gnome.org/doc/API/ Lists: http://mail.gnome.org/archives/gtk-devel-list/ http://mail.gnome.org/archives/gtk-app-devel-list/ http://mail.gnome.org/archives/gtk-list/ GLib Bugs: http://bugzilla.gnome.org/buglist.cgi?query=product:glib Gtk+ Bugs: http://bugzilla.gnome.org/buglist.cgi?query=product:gtk%2B [*] Please sign up for a task by adding your real name and a working email address. Multiple people may sign up for a task, they should communicate with each other to avoid duplication of effort however. [1] Bugs regularly need to be sorted out and patches filed therein need to be tested and possibly adapted. A detailed description is given here: http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html (Re: Supporting Gtk+ Maintenance) [2] Patch snippets that get pasted/submitted via email/irc/etc. and that core developers can approve off head still need to be actually applied, compiled, tested with our test suite, be committed and potentially back- merged onto other branches. Someone signing up for this should have reasonable C knowledge, hang out on #gtk+ and be frequently reachable via email. Ideally people signing up for this
