Re: libgnomekbd development

Hello Antonio No actually I do not maintain it, not touching any GNOME code for a while. Regards Sergey On Thu, Jan 21, 2016 at 6:59 PM, Antonio Ospite wrote: > Hi, > > I have several patches for libgnomekbd[1], I submitted some of them to > bugzilla[2,3,4] but nobody seems to

Re: libgnomekbd: dead man walking

Ok. If you have a team of zombies, let them walk till 3.8 On Fri, Aug 24, 2012 at 3:57 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Thu, Aug 23, 2012 at 10:12 AM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: Hi ppl With the recent developments related to input methods

libgnomekbd: dead man walking

Hi ppl With the recent developments related to input methods, libgnomekbd is effectively redundant. The only useful bit remaining is the layout preview widget. IMNSHO those bits can be quickly integrated into g-c-c without breaking things. I am not aware of any other project that would use

Re: libgnomekbd: dead man walking

I don't want to move such a large amount of code without review or thorough testing, so I'd like it if libgnomekbd was still shipped in GNOME 3.6. There is only one .c and one .h file (and one small .ui). Is that a large amount of code? All other c/h files are dead code. Waste of builder's

Re: libgnomekbd: dead man walking

Also past UI freeze, and I'm already busy trying to bug fix all the new features we added this cycle. That'll do. I'll do the releases if you don't want to do them... The UI freeze would not be broken - it will just be moved from one module to another. I can do the release, no problem. I just

Re: libgnomekbd: dead man walking

I would ask if the ~/.xmodmap support was not part of this? Or is it part of gnome-settings-daemon now? It was in g-s-d. Now it is in libxklavier. But since g-s-d these days is not using libxklavier, I do not know about the current state of .xmodmap support. Perhaps Rui can comment...

Re: IM Integration: Let's demonstrate our languages in the Wiki

On the Wiki page I see TODO: List of keyboard Layouts. Are you going to list all layouts/variants available in xkeyboard-config? Plus the ones available from the IM framework(s) supported by GNOME? Actually, the list of layouts from xk-c can be done dynamic, by extracting from base.xml.in

Re: Some points about IM integration

I've heard enough of this and feel great disrespect. Please Marguerite, let's not get personal (or even national) on this thread. You should know better than occusing people who sincerelly want GNOME to provide the best - and do not mean any nationalism or disrespect. But really there is another

Re: 3.6 Feature: IBus/XKB integration

I do not want to see iBus integration becomes another Power Off Button on GNOME Shell. IMHO the useful discussion should be from two directions. One direction - from the user POV. Here, the goal is to define the experience that would make CJK (and other) users happy. To collect the requirements

Re: 3.6 Feature: IBus/XKB integration

We only have the development resources to ship one input method. It's going to need special code to integrate with Clutter and the St toolkit. If IBus is bad right now, we need to fix it. Some while ago when I started libxklavier, there was idea to create some kind of abstraction layer for xkb

Re: 3.6 Feature: IBus/XKB integration

I didn't want to imply that. What I meant was that XI2 provides with better and more forward compatible event structures, that allow us to lift the restriction. Noone argues. The xserver, xkeyboard-config, libxkbcommon, libxklavier, libgnomekbd and other internal libraries will of course

Re: 3.6 Feature: IBus/XKB integration

It isn't so much how people configure their keyboards as how they (a) switch between different languages/alphabets So, this means the option group grp:* is included. Which is obvious anyway... (b) insert special characters. Thus, misc:typo should be there, right? It was mentioned in your

Re: 3.6 Feature: IBus/XKB integration

It costs in terms of maintenance, certainly. There's exactly one person in GNOME that knows libgnomekbd and libxklavier, and that's you. Well, considering that people submit useful patches to those libs, there is some shared knowledge. But in general you are right. We have the most dreadful

Re: 3.6 Feature: IBus/XKB integration

https://plus.google.com/u/0/100040579167442382687/posts/QTFCr48xNkj I did not know about that interesting survey. Quite insightful. Would it make sense to make a formal research before pushing some options/groups out? ___ desktop-devel-list mailing list

Re: 3.6 Feature: IBus/XKB integration

What is being dropped is the ability to override that. That is exactly what that survey shown: people want to be able to override that. (Is Google+ full of anything but geeks nowadays?) The fallback argument this feature is useful for geeks only is going GNOME a bad job, all the time... It

Re: 3.6 Feature: IBus/XKB integration

That's the part of the user base that answers to polls in Google+. Right. That is why noone says use those answers from Google+ literally. It would be nice to find the way that would protect the results from the anti-geekness argument. But not having any survey results, making arbitrary decisions

Re: 3.6 Feature: IBus/XKB integration

I don't think you can infer that from the answers. I'm one of the people who said they use Compose. I don't particularly care which key it is, as long as I can reach it without taking my hands away from home row. Well, a number of people say they use Compose - a number of people say they map

Re: 3.6 Feature: IBus/XKB integration

I cannot speak for the Design Team, but I'm pretty sure their decisions are not arbitrary. My apologies, if the word arbitrary is offensive, I did not meant any offense. But without surveys, without explanation any filtering decision would be arbitrary by nature, right? Sergey

Re: 3.6 Feature: IBus/XKB integration

, Apr 25, 2012 at 2:47 PM, Allan Day allanp...@gmail.com wrote: On Wed, Apr 25, 2012 at 2:43 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: I don't think you can infer that from the answers. I'm one of the people who said they use Compose. I don't particularly care which key it is, as long

Re: 3.6 Feature: IBus/XKB integration

I think that our past experience with surveys done in the context of GNOME have shown that this sort of survey isn't useful. How would you check the user's opinions then? To get some objective, measurable results, that would not depend on interpretation by biased (to non-geeks) decision makers?

Re: 3.6 Feature: IBus/XKB integration

       Fred (using the right Ctrl key for Compose) rwin here :) So much for What is being dropped is the ability to override that. :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: 3.6 Feature: IBus/XKB integration

Hi Rui Everything else will continue to work (or not work) as it does now I'm afraid. The imsettings package in Fedora takes care of setting up some environment variables according to the user's locale at login time which should continue to work. Of course any switching the user does at

Re: 3.6 Feature: IBus/XKB integration

No, I don't think xterm supports any kind of input method. xterm will just work as it works now. Right. That's what I expected. Let's sat you have two layouts - in XKB and IBus, for the same country. The user would be presented with only one - IBus (if you decided it is superior, which it may

Re: 3.6 Feature: IBus/XKB integration

As long as the user is free to quickly switch with a shortcut to whatever other input source he wants I don't see that as a problem. Well, if you do not provide GUI tools to configure the conflicting XKB layout, the process is going to be cumbersome. Can you elaborate on that? What exactly

Re: Request: bump libxklavier dependency for libgnomekbd

Thank you very much! libgnomekdb will be fixed ASAP. On Tue, Feb 14, 2012 at 3:57 PM, Javier Jardón jjar...@gnome.org wrote: On 17 January 2012 23:05, Sergey Udaltsov sergey.udalt...@gmail.com wrote: Hi all The new version of libxklavier (5.2) introduces proper introspection

Request: bump libxklavier dependency for libgnomekbd

Hi all The new version of libxklavier (5.2) introduces proper introspection. For the introspection in libgnomekbd to link properly to libxklavier objects, it is necessary to require new libxklavier 5.2. Would anyone have any objections? Thanks, Sergey

Re: GNOME user survey 2011 (v6)

Would anybody have time to prepare some useful survey? Provocative question: is there any way that some unbiased survey would change the emphasis of development from gnome-shell to the fallback mode? And increase the configurability and so on.. Or - the current strategy is unchangeable

Re: GNOME user survey 2011 (v6)

Iirc the fallback mode is using new gtk and stuff... why is it obsolete? I was asking looking at the anger and nostalgie expressed on phoronix. On Oct 18, 2011 5:29 p.m., Cosimo Cecchi cosi...@gnome.org wrote: On Tue, 2011-10-18 at 17:15 +0100, Sergey Udaltsov wrote: Provocative question

Re: GNOME user survey 2011 (v6)

AFAIK the goal was to only maintain it until the very last graphics chip in use was able to run shell. It's not there as a preference, it's a fallback mode for unsupported hardware. Absolutely! My question was exactly about that - is there theoretical possibility that proper survey would amend

Re: GNOME user survey 2011 (v6)

for too long. Usage seems to be minimal. But not a lot of distributions have GNOME 3 yet, so it is also a bit early to tell. Exactly. Let's wait till all distros outphase gnome 2.x ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: GNOME user survey 2011 (v6)

What's stopping these deprived users from using Gnome 2.X? I don't think there's enough developers interested in keeping the 2.X series alive - it would be a different matter if people were smashing out the features/patches for the 2.X range but as that's not happening I don't see why they

Re: GNOME user survey 2011 (v6)

I really want to drop in here. I on purposely say gnome instead of you to avoid giving the impression that i attack anyone. Mark, I am afraid that still looks like an attack... While in general I agree with you, I guess the format of your message is not appropriate. It does not make sense to

Re: GNOME 3.2 Blocker Report for week 35

libgnomekbd: layout indicator issues https://bugzilla.gnome.org/show_bug.cgi?id=642703 Patch available awaiting review. Actually that patch was committed long ago. Will close the bug now. Sergey ___ desktop-devel-list mailing list

Re: Formal complaint concerning the use of the name System Settings by GNOME

This is what happens when you mix and match bits and pieces from different operating systems. There is really not much that can be done about it. Since that is what both KDE and GNOME are trying to do: build complete, self-contained systems. So far we are running the same OS (for most of us it

Re: systemd as external dependency

Yes, it might cost us a bit to be open and friendly like this -- and to be honest, I'm not convinced the cost is that high for GNOME code, while it certainly is for systemd -- but our community is not just about purely technical matters. We also care about being open and friendly. Or at

Re: systemd as external dependency

I think the best way to save resources is not to run anything. For stuff like hostnames/locale/time which is used only every other moonphase having tiny single-purpose mini-services is perfectly appropriate. I don't think there would be any benefit in merging these mini daemons into one. Au

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

Distribution differences are something to be avoided, not encouraged. It is not for gnome to decide. See the messages from Ross. Differences are inevitable. Let's embrace differences, let's minimise patches. Let's be friendly to downstream. Anyway, since distros are patching in their capplets -

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

least. it has a painful transition, but it's working pretty fine for now. Oh really? What is your criteria of success? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

Right. All I asked from the start is documenting the current vision. Seems continuing this discussion on desktop-devel-list is not going to change anyones mind ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

I don't see this happening. Are you talking about GNOME 3 or GNOME 2.x here? Gnome3, since gnome2 did not have the goal to define the final experience. And it was more open. The whole design part is new. My view is that we're way more friendly to do things for downstream. What kind of

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

Could someone please articulate the GNOME position for downstream distributors of GNOME technologies?  It seems to me the previous position was to use the extension points instead of doing vendor patches.  Yet, without extension points it seems that vendor patches are the only solution there.

Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]

For something like this, I have a feeling we may only get one chance. If you don't allow any differentiation on top of GNOME, there is at least one distribution that will just do preferences differently ignore control-center. And I can imagine that future environments along the lines of

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

No, GNOME is not a supermarket. It's not a place where you go to get your technology so you can put it together in your own sandbox. This might be inconvenient for downstreams (including my employer) but it is what it is. The fact that you _can_ (easily) fork GNOME just happens to be a

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

Extension- and plug-in systems is often the symptom of a disease. How would you distinguish...? [1] : Except of course if some downstreams do development in their own fucking sandbox.. no, this is not a cheap jab at Canonical.. it includes e.g. Red Hat too. Or SUSE. Thank you, that is very

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

I don't know. It's typically a highly subjective thing. Mostly it comes down to what most people refer to as good taste vs bad taste. I don't know. Fair enough. Not showing 3rd party panels is one path forward. And I think it's the right one. If all distros just patch in their own panels,

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

I totally agree, IMHO GNOME is a base to allow distributors, vendors and third parts to build up and extend their own user experience and services and fight on free market. No competition means stagnation. Yes, very true. GNOME wants to dictate some policies. Fair play, because we own the code.

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

We're not dictating anything; we're just making an awesome OS, the way we envision, period. Wait a sec. It was said (here and on IRC) that g-c-c wants to include only polished panels to g-c-c. Only panels that gnome UI specialists are happy with. It is a form of dictate - or I do not know what

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

Then, as I said on another reply, why are gnome-shell extensions allowed to change gnome-shell so deeply[1]? More, why is gnome-shell providing support to extensions? Symptom of disease, obviously. Lethal. ___ desktop-devel-list mailing list

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

This is just absurd - distros were never supposed to compete with each other (if I had my way, anyway) It was not me who brought the idea of external competition here;) Anyway, are you saying that all distros would be happy to use identical UI? You know what I think is selfish? Treating GNOME

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

I honestly don't understand. Didn't I just put it in words ? Of course, I didn't say 'twist hands', since I disagree that that is what we are doing. I would go for 'insisting on design, integration and quality'. I was asking to create a document (on live.gnome.org) where all those things would

version requirement request: libxklavier 5.1

Hi folks Retrospectively I am asking (or rather informing) that new kbd layout dialog, recently designed here: http://live.gnome.org/Design/SystemSettings/RegionAndLanguage required some changes in libxklavier API. So the minimum version will be 5.1 (not yet released, to be released ASAP). For a

RFC : gnome and non-linux oses

Hi folks Yesterday, the code supporting choosing xkb model was removed from control center - because on linux all keycodes are based on evdev (techically correct statement - but only for linux) and noone really cares about geometry. Is there official policy related to supporting gnome on

Re: RFC : gnome and non-linux oses

In this particular case, I'm the one who removed the code. To be honest, I'm not even sure that changing the keyboard model would have been all that useful on any slightly recent Unix-like OSes. As far as I know, on other OSes it was, because they do not have evdev. But of course the input

Re: My thoughts on fallback mode

This modularity prevents to create a solid user experience in various ways because everything needs to be compatible with random components that cannot even be tested properly. I cannot believe I am reading this on GNOME central mail list! Is this the same GNOME that helped to improve WM

Re: My thoughts on fallback mode

These standards are there to make sure GNOME *apps* are first-class citizens in other DEs ( vice versa). It has little to do with being able to play mix-and-match with core desktop components. From X11 POV gnome-shell is just an app. Why should it depend so heavily on features of some

Re: My thoughts on fallback mode

Maybe because it's using Clutter, and no WM other than Mutter allows displaying windows as Clutter actors? The Shell isn't external to the WM, it lives in the WM, and thus depends on its peculiarities. Could that be standardized? ___

Re: My thoughts on fallback mode

I cannot believe this topic keeps coming up again and again :-( Linux is not about choice: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html You know why this happen again and again? Because ppl want it to be about choice. Sergey AKA Capt. Obvious

Re: My thoughts on fallback mode

Somehow I suspect that non-developer users on desktop-devel-list do not represent a majority of GNOME users. Well, the world is bigger than this ML and I never said that the majority is complaining, just that 1% is not the truth. Compared to how many users stuff like Compiz, AWN Co got I

Re: My thoughts on fallback mode

Hi Owen Thanks a lot for expressing reasonable and really sane point of view!  * There will also be some people that want to use gnome-panel because   they aren't ready to change. While we want to encourage people who   have capable hardware to update and use the new experience, there   are

Re: My thoughts on fallback mode

to clarify: What exactly do you expect from the release team? Some more positive attitude to gnome-applets, first of all. Looking at the gnome-applets thread I got impression that RT was not going to accept gnome-applets under any circumstances. The message I got was anyone is free to maintain

Re: Re: gnome-panel gnome-applets?

Don't think there is 3d on ppc. There is. I have it on Power G5. I think the fact that GNOME kills gnome-applets make GNOME2 compatibility mode a bad joke (if not hypocrisy). A good number of people would like to use that mode (I run voting some while ago at linux.org.ru - can provide url if

Re: Re: gnome-panel gnome-applets?

What you want is not Gnome 3 then. You want to continue using Gnome 2 and there's no one preventing you from doing that. So, why bother maintaining gnome2 support mode at all? go to hell, just do not upgrade is unbeatable argument, I must admit. Actually, your advice effectively stops people

Re: Re: gnome-panel gnome-applets?

As pointed out before the fallback-mode is not a continuation of GNOME 2. It was just the easiest way to create a fallback because we don't have the resources to create a non-3D shell that could act as a fallback. As we have gnome-panel already it was choosen as the fallback mode. Is it an

Re: Re: gnome-panel gnome-applets?

It seems, there are, in theory, 5 options for fallback/compatibility: 1. Make g-s and mutter scalable down to envs without 3d 2. Provide full compat/fallback mode, with panel and applets 3. Provide restricted fallback mode, only gnome-panel, just enough to do smth 4. Same as #3, just very basic

gnome-panel gnome-applets?

I am confused, what's the story with gnome-panel and gnome-applets in 3.0? Are they in, are they out? If gnome 3 is to support gnome2 compat mode, both of these components should stay in for some while, right? Currently, the situation in in jhbuild is very strange: gnome-panel is still there,

gnome2 and gnome3: strategy of coexisting

Hi folks I am not sure if I missed that topic (apologies if I did). Is there a strategy regarding co-existing of gnome2 and gnome3 on the same system? Obviously there is going to be some transitional period, when people would play with two generations. Distributions might want to have two sets

Re: gnome2 and gnome3: strategy of coexisting

and do not care (and we do not help)? On Mon, Oct 11, 2010 at 10:23 PM, Bastien Nocera had...@hadess.net wrote: On Mon, 2010-10-11 at 22:16 +0100, Sergey Udaltsov wrote: Hi folks I am not sure if I missed that topic (apologies if I did). Is there a strategy regarding co-existing of gnome2

Re: gnome2 and gnome3: strategy of coexisting

would not mind seeing 2.34, 2.36, ...2.98, 2.100, 2.102, ... - just less bugs and a wee bit of more features, here and there;) On Mon, Oct 11, 2010 at 11:06 PM, Olav Vitters o...@vitters.nl wrote: On Mon, Oct 11, 2010 at 10:37:36PM +0100, Sergey Udaltsov wrote: Thanks for the answer. So, does

Re: Label in tray = P in the A

. Cheers, Sergey On Wed, Mar 24, 2010 at 3:26 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Wed, Mar 24, 2010 at 11:15 AM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: No, I meant put it in the icon, like an emblem. What kind of emblems? For example for Usa and Russia

Re: Label in tray = P in the A

Thanks, that looks promising! Sergey On Wed, Mar 24, 2010 at 1:41 AM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 03/23/2010 09:06 PM, Sergey Udaltsov wrote: Thanks Matthias How could I tell pango about hinting and AA settings? I could not find that in pango API, only in cairo

Re: Label in tray = P in the A

. What would be the acceptable solution? Just leave it as it is? Use two status icons (hehe, joking)? Use flags (joking even more)? Any ideas are welcome. Sergey On Wed, Mar 24, 2010 at 12:01 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: Thanks, that looks promising! Sergey On Wed, Mar 24

Re: Label in tray = P in the A

Not an options. This is INDICATOR. That's a primary function. Switching is a secondary function. Sergey On Wed, Mar 24, 2010 at 1:43 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Wed, Mar 24, 2010 at 9:20 AM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: Thanks lads, the idea

Re: Label in tray = P in the A

Translated. Typically, 3 letters (well, at least that's my recommendation as maintainer of xkeyboard-config). On Wed, Mar 24, 2010 at 2:15 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: And all in Latin, or translated?  How many letters typically? On 03/24/2010 10:08 AM, Sergey Udaltsov

Re: Label in tray = P in the A

, Sergey Udaltsov a écrit : Translated. Typically, 3 letters (well, at least that's my recommendation as maintainer of xkeyboard-config). Can't you fit these letters in a square, as small as it may be? I don't see any other solution to your problem. Regards

Re: Label in tray = P in the A

Yes, algorithmically that is straightforward. Sergey On Wed, Mar 24, 2010 at 2:21 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 03/24/2010 10:18 AM, Milan Bouchet-Valat wrote: Le mercredi 24 mars 2010 à 14:17 +, Sergey Udaltsov a écrit : Translated. Typically, 3 letters (well

Re: Label in tray = P in the A

...@gmail.com wrote: On Wed, Mar 24, 2010 at 10:08 AM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: Not an options. This is INDICATOR. That's a primary function. Switching is a secondary function. Make the text an overlay on the keyboard icon then. Just having the three letters U S

Re: Label in tray = P in the A

No, I meant put it in the icon, like an emblem. What kind of emblems? For example for Usa and Russia? How about making it Keyboard layout: USA ? NP ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: Label in tray = P in the A

I am sorry, you lost me here. How could the label be the emblem? You mean some kind of word-art? Sergey On Wed, Mar 24, 2010 at 3:26 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Wed, Mar 24, 2010 at 11:15 AM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: No, I meant put

Re: Label in tray = P in the A

This is perfectly valid point. Thanks for telling me. I intended to use 3166 alpha-3 but some codes might get messed. I will try to check that. Sergey On Wed, Mar 24, 2010 at 11:09 PM, Luca Ferretti lferr...@gnome.org wrote: Il giorno mer, 24/03/2010 alle 14.17 +, Sergey Udaltsov ha scritto

Label in tray = P in the A

In GNOME 2.30, the kbd indicator moved to the tray. People are happy, most of them. But ... there is a trouble. StatusIcons are not GTK widgets. And, as the result, the indicator has to emulate gtk widget. That's a real pain, folks. The indicator renders text to cairo, converts cairo to pixbuf,

Re: Module Proposal: Rygel

Samba is software for big installations, and primarily used on non-desktop servers. Well, it _serves_ files, so it is natural to expect it to be on servers. But I do not know what exactly positions it as for big installations. Samba is found in set-top-boxes, on mobile devices (I just seen it on

Re: Module Proposal: Rygel

 From reading description, it seems to me that Rygel would be better suited as system service. Just like for example mt-daapd (which seem to have the same purpose as Rygel but for DAAP). How does it fit GNOME? Absolutely correct point! Folks, when did you decided that GNOME is for PCs only

Re: Module Proposal: Rygel

  Just because others do it in a particular way, doesn't make it right. Although Rygel can be run as a system-wide service, the main target use-case is that of providing services per-user[1] so for example each user can choose to share his media on the network rather than every user's media.

Re: Module Proposal: Rygel

Popcorn Hour can do both CIFS and UPnP, and I use CIFS :P On Mon, Feb 22, 2010 at 4:05 PM, Ross Burton r...@burtonini.com wrote: On Mon, 2010-02-22 at 14:29 +, Sergey Udaltsov wrote:   Just because others do it in a particular way, doesn't make it right. Although Rygel can be run

Re: libxklavier: version bump to 5.0

It would be very appreciated if you could introduce as many as possible of the changes in libxklavier in an ABI-compatible way. This library is also used by KDE and Xfce, and every time this requires synchronised updates, or even porting, of a number of packages. I am doing my best, but

libxklavier: version bump to 5.0

Hi ppl I request permission to bump the required libxklavier version to 5.0 on wiki page. The library API was changed to facilitate latest changes in gnome-settings-daemon and gnome-applets - i.e. phasing out of the indicator applet, and using notification icon (implemented in g-s-d keyboard

Re: external dependency libxklavier: request to bump the version

I thought I updated g-a. I will check. About gdm - thanks, I forgot it! Sergey On Wed, Jul 1, 2009 at 2:50 PM, Matthias Clasenmatthias.cla...@gmail.com wrote: On Wed, Jun 24, 2009 at 9:23 AM, Sergey Udaltsovsergey.udalt...@gmail.com wrote: Hi folks Is there anyone objecting to bump the

external dependency libxklavier: request to bump the version

Hi folks Is there anyone objecting to bump the required version of libxklavier to 4.0 (to be released this week or so)? The new version is going to support new feature of xkeyboard-config - exotic/extra layouts (see http://bugs.freedesktop.org/show_bug.cgi?id=21466). This caused some changes in

gnomethree: what about log4G?

Hi folks The issue of unified logging was raised long ago, but did not get much attention. I guess, it might be the right time to raise it again. A number of gnome modules is using some kind of logging, 1-2 source code files . Why does not glib provide some API like log4j which could be

cgit annotate

Small feature request: Would it be possible to see source code annotated in cgit? Thanks, Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list

libxklavier: request for the minimum version change

Hi folks Does anybody mind changing the minimum version of libxklavier (in deps) - to 3.8? Only g-s-d is affected, new signal is introduced (for the keyboard hotplugging). Thanks, Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: new module proposal: notification-daemon+libnotify

But even if he is too busy to propose the module himself, I think it is time for us to be honest about the fact that it is pretty much impossible to use the desktop without notification-daemon nowadays. I can only second that. Some while ago, I offered g-s-d to use notification for all kind of

Re: External dep version bump: libxklavier to 3.6

gnome-control-center trunk now depends on libxklavier 3.6. It was 3.3 previously as listed on [1]. Do we agree to raise the external dependency to 3.6? From a brief glance at the Changelog mainly bugfixes and some code cleanups were done. There was important addition to libxklavier API

Re: External dependency, libxklavier: request for version change

: On Wed, 30 Jan 2008 23:55:05 + Sergey Udaltsov [EMAIL PROTECTED] wrote: Hi all hi, I just released libxklavier 3.4 and would like to change the version in the list of GNOME external dependencies on wiki (http://live.gnome.org/TwoPointTwentyone/ExternalDependencies). Any objections

External dependency, libxklavier: request for version change

Hi all I just released libxklavier 3.4 and would like to change the version in the list of GNOME external dependencies on wiki (http://live.gnome.org/TwoPointTwentyone/ExternalDependencies). Any objections? No API changes were made, no changes in GNOME code are required. Thanks, Sergey

Re: Input devices capplets

how so? it belong to the layout part, which is in the localization capplet mockup Denis sent a while ago, and which I should be getting to life soon (sorry, quite busy, and I've got just a very little code done, but will try to have a first version before the end of the week) Well, if you

Re: Input devices capplets

In the keyboard capplet it would be good to add on the Layouts tab the option to configure the keyboard shortcut used to switch between layouts. Currently this option is located in the Layout Options tab, inside Group Shift/Lock behaviour, towards the end of the list. This options group is one

Re: Input devices capplets

About the many tabs: at least the Layouts tab could move to the i18n capplet when we have finished it. Oh really? But what about the Layout Options popup? It does not really belong to i18n... Sergey ___ desktop-devel-list mailing list

Re: Please include into 2.22: libnotify, notification daemon

Personally, though, I still think libnotify would be very useful throughout GNOME and should be a blessed dependency. Should it be listed in the list of proposed dependencies on l.g.o? I mean http://live.gnome.org/TwoPointTwentyone/ExternalDependencies Cheers, Sergey

libgnomekbd branched for 2.20

Here is just to inform you that libgnomekbd is branched for 2.20. TWIMC, the 2.22 version is going to make indicator widget lightweight (no stupid dbus client-server any more, so a bit of fat would be taken off g-s-d). The price of that would be bumping requirement for libxklavier version - from

  1   2   >