Re: 3.6 Feature: Lock Screen
(sorry it took me this long to reply...) 2012/5/12 Marina Zhurakhinskaya : > The overall plan sounds good. Some comments are inline. > > >[...] > >> It then listens for >> GrabBroken events and immediately grabs keyboard and mouse in sync >> mode. > > GrabBroken is something that is sent by gdk within each process. So > gnome-shell would receive it if something causes the composite overlay window > to loose the grab or the guardian process would receive it if something > causes its window to loose the grab (see > http://developer.gnome.org/gdk/stable/gdk-Event-Structures.html#GdkEventGrabBroken > ) - but the guardian process would not receive a GrabBroken event when a > gnome-shell window looses the grab. (Besides, a process would only receive > GrabBroken if it is running past the time when one of its windows looses the > grab, so when gnome-shell crashes it would not receive GrabBroken event > itself either :). > > What the guardian process can do is watch for the gnome-shell name on DBus > going away, so that it is notified if gnome-shell stops running. Ugh - that's a problem. Weird X has no notification of grabs going away. In any case watching dbus is probably the right thing to do (or may be looking for EnterNotify on the guardian window, which would be syntethized by X upon removing the grab?) >> It is controlled by g-shell via dbus (possibly dbus-activated >> too), and would relinquish grabs and replay events when gnome-shell >> is >> ready to take them again, or when the fail whale is displayed from >> g-session. > > I think it's ok for the events that happen while gnome-shell is down to be > lost. So the keyboard and mouse can be grabbed asynchronously and the events > don't need to be replayed. Ok. I don't think it makes much difference, although it avoids us going down to Xlib. Btw, for now I'm concentrating on the PAM/gdm stuff, so this extra locking part will come later. Giovanni ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Some points about IM integration
On 05/15/2012 10:17 PM, Rovanion Luckey wrote: > Greetings all, > > This fall I and three other students did an accessibility study in > which Dasher was a part. One of the issues we encountered was that the > user after having typed it's sentence or any other text into Dasher > had to copy and paste it into the application they were actually > using. And if they later discovered an issue in the text they'd have > to copy it back to Dasher, edit it and then copy and paste it to the > application again. This copy and paste is not required for most of the apps. I have just tried with gedit and I was able to write text with dasher without this copy and paste process. Hint: in order to do that you need to use the option "direct" $dasher -a direct Having said so, and elaborating "most of the apps": in the case of gnome-shell this copy and paste is required on the overview, as there isn't a full integration in that case. > > If this hasn't changed since then and without having any knowledge of > the input management code or the Dasher code I would like to ask a > question: Wouldn't it be great to have Dasher appear when a text field > is activated in Gnome much like it does on Android[1]? "direct" was a Dasher option since years. About having Dasher appear when a text field appear, yes I guess that it would be a fine improvement. > > The Input Manager is called when the text area is activated. It then > puts characters in the field. This has been a great success on Android > with the most popular keyboard in the store being installed on about > 100.000 devices. Couldn't something of the sorts be done in Gnome for > on screen keyboards, accessibility tools and other input managers like > the one discussed in this thread? They all seem to do the same thing, > just in different ways. Obviously there is a relation between alternative keyboard inputs (including on screen keyboards and apps like dasher) and input methods. BR -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome goals for 3.6
2012/5/16 Matthias Clasen :
> Sometimes you can eliminate the markup by doing something like
>
> s = g_strdup_printf ("%s", _("fallback mode"));
> /* Translators, %s stands for 'fallback mode' here */
> msg = g_strdup_printf _("Unfortunately GNOME 3 failed to start
> properly and started in the %s"), s);
Please don't as "fallback mode" then has 90% probability of using a
wrong grammatical case (ie. nominative).
--
Patryk Zawadzki
I solve problems.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: application menu design - contributing to the wiki on live.gnome.org
Hey! Feel free to use the playground space for your ideas. That's what it's there for. :) Allan On Wed, May 9, 2012 at 5:00 AM, Pigeon Lips wrote: > Hi All, a very friendly person on the gnome IRC put me on this mailing > list. > > Long story short i wanted to add an article to your design > wiki https://live.gnome.org/Design/Playground but thought it best to run it > by someone first. > > after reading this https://live.gnome.org/Design/Whiteboards/Menus i was > inspired by the mega menu. I would like to try a mock up of extending this > concept further and wanted a place to post my thoughts, mock ups and > suggestions on how a nice mega menu could be extended via search and context > driven actions. > > Is this an ok thing to do, or do i need to flesh out the idea here first ? > > thanks. > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Some points about IM integration
Hi Owen, I heartily agree with this a statement of direction to pursue; standardization is a good principle. But there is the matter of the timetable for rolling this out -- considering the feedback from CJK users, I think assessment is needed of what work should be done on the chosen framework *itself* before a sound decision on whether the standardization should happen in the 3.6 cycle can be made. Tomas On 15/05/12 00:27, Owen Taylor wrote: > In general, choice of input method framework is not a goal in itself. > If we choose a single input method framework to integrate with GNOME - > that doesn't make GNOME like proprietary software from Apple and Microsoft, > because GNOME will still be 100% Free Software, and will still be developed > in the open by the GNOME community. > > GNOME doesn't want to work well just for tweakers and enthusiasts - it's > very important to the project that GNOME works well for all users without > tweaking. We want to give the choice of using Free Software to > everybody - this is a much more fundamental form of choice than giving a small > group of users the ability to swap out a different input method framework > underneath GNOME. > > GNOME isn't just a set of parts that a Linux distributor takes and uses > to create a working system - we also take responsibility for creating > a fully working system. This means deciding how GNOME interacts with > system components like sound and networking and printing and when necessary > enhancing those components to provide the right experience to the user. > > So we can't leave it up to one Linux distributor to combine GNOME with > fcitx to make a version of GNOME that works well for zh_CN and another > Linux distributor to combine GNOME with RIME or hime to make a version > of GNOME that works well for zh_TW. We want GNOME to, without customization, > work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth. > > Of course, it would be a mistake to think that a small group of English > speaking developers could make GNOME work well in all these languages. That > would be impossible! But from experience, we know that simply leaving a > problem like this to external developers and hoping for the best doesn't > work out well. Instead we need to engage users and developers from these > language communities into the GNOME development community. > > I don't want to minimize how easy that is - I know there are very significant > barriers of language, timezone, and distance that make this hard. I know > that bugs get ignored and patches sit around unreviewed. But still, > active engagement is the only way forward. I think it's absolutely wonderful > how many people have gotten involved in the current discussion! > > We also need to keep in mind that we aren't talking about the choice of input > method, we are talking about input method *frameworks*. The basics of passing > events from application to daemon, loading different input method backends, > handling hotkeys and displaying feedback are going to be very similar for > all East Asian languages. > > Things like displaying feedback may be a little different if we move further > afield to Thai or Hindi - but still, there is no fundamental reason that they > need a different *framework*. > > Using a single input framework for all GNOME users has many benefits. > GNOME developers can reproduce bugs that users run into. Bugs only have to > be fixed once, not in multiple frameworks. We can actually figure out how > to make input methods work with onscreen keyboards and accessibility. Our > designers can collaborate on making the configuration dialogs conform to > GNOME standards. > > Finally, using a single input method framework is pretty much essential to > the goal of allowing users to configure languages at runtime with a nice user > interface. If language A and language B require different input method > *frameworks*, there is no way that the user can switch between them with a > hotkey. > > In general, I don't see standardizing D-Bus interfaces so that GNOME can > work with multiple input method frameworks as being a useful activity. > If the D-Bus interfaces are carefully maintained and changed only with > agreement and advanced notice, then they will impede the progress of bug > fixing and making things better. If the interfaces are not carefully > maintained, then they aren't standards at all, and users will constantly > encounter breakage. > > And in any case, as described above, there has to be *one* framework that > works as well as we can possibly make it for all users. Multiple partially > working frameworks are not a substitute. > > All of the above is an argument only for picking a single input method > framework. It doesn't say anything about what input method framework we > should pick. The fact that the IBus developers have been engaged with > GNOME for quite some time and are willing to work with us to create a user > experience that is simple and consis
Re: application menu design - contributing to the wiki on live.gnome.org
On Wed, May 09, 2012 at 04:00:53PM +1200, Pigeon Lips wrote: > Long story short i wanted to add an article to your design wiki > https://live.gnome.org/Design/Playground but thought it best to run it by > someone first. > > after reading this https://live.gnome.org/Design/Whiteboards/Menus i was > inspired by the mega menu. I would like to try a mock up of extending this > concept further and wanted a place to post my thoughts, mock ups and > suggestions on how a nice mega menu could be extended via search and > context driven actions. > > Is this an ok thing to do, or do i need to flesh out the idea here first ? Hi, Just add your page somewhere below that Playground page. To contact the design people, best to use IRC (#gnome-design on irc.gnome.org). As it is IRC, might take a while before someone responds. But just state your ideas and if someone is around, they'll respond. I think US working hours is best time to try. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
