Re: libgnomekbd development

[Sergey Udaltsov]

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 have commented on them in more
> than a year.
>
> How do I have to proceed to have them reviewed and possibly merged?
> Sergey, do you still maintain libgnomekbd?
>
> Thanks,
>Antonio
>
> [1] https://git.gnome.org/browse/libgnomekbd/
> [2] https://bugzilla.gnome.org/show_bug.cgi?id=734618
> [3] https://bugzilla.gnome.org/show_bug.cgi?id=734619
> [4] https://bugzilla.gnome.org/show_bug.cgi?id=734621
>
> --
> Antonio Ospite
> http://ao2.it
>
> A: Because it messes up the order in which people normally read text.
>See http://en.wikipedia.org/wiki/Posting_style
> Q: Why is top-posting such a bad thing?
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: libgnomekbd: dead man walking

[Sergey Udaltsov]

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 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 libgnomekbd. If you know about such dependency - please
 please raise your voice!!!

 I discussed that with Rui, he generally agrees but there is valid
 concern about dependencies.

 The code will say in git (master and 3.4 branch), I just think the
 library should not be a part of 3.6 release - and there will be no
 further development.

 Anyone has any comments? Technically that should be a very cheap operation.

 Hey Sergey,

 thanks for bringing this up. Given what Bastien said, I guess it will
 be best to do this dependency cleanup early in 3.7, and keep
 libgnomekbg around for the 3.6 release. It will certainly not be the
 only 'dead man walking' in our moduleset...


 Matthias
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

libgnomekbd: dead man walking

[Sergey Udaltsov]

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 libgnomekbd. If you know about such dependency - please
please raise your voice!!!

I discussed that with Rui, he generally agrees but there is valid
concern about dependencies.

The code will say in git (master and 3.4 branch), I just think the
library should not be a part of 3.6 release - and there will be no
further development.

Anyone has any comments? Technically that should be a very cheap operation.

Sergey

PS libxklavier remains to be maintained, I know some people are using it
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: libgnomekbd: dead man walking

[Sergey Udaltsov]

 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 time.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: libgnomekbd: dead man walking

[Sergey Udaltsov]

 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 feel awkward releasing the
library most of the code of which is dead...

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: libgnomekbd: dead man walking

[Sergey Udaltsov]

 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...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Sergey Udaltsov]

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 (proper xsl or smth)

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Some points about IM integration

[Sergey Udaltsov]

 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 side to it. The worst thing that happened
to GNOME3 comparing to GNOME2 is that for nearly every aspect GNOME3
is trying to find THE solution (for the valid reason of polished UX) -
and without specifying managed interfaces, all other solutions just
have zero chance to compete (so THE solution immediately becomes THE
ONLY POSSIBLE solution). I am really excited to see that this approach
demonstrates its fundamental weakness in case of IMs - that gives
another chance to everyone to think about general GNOME strategy, to
start thinking in terms of interfaces, not particular implementations.

I understand that GNOME devs would be happy to choose IBus as the
default solution, since it is most GNOME-oriented and the integration
can be as tight as GNOME high UX standards would require. Quite
possible that is sane. But it was told here that IBus (fundamentally?)
lacks some substantial features that other IM frameworks have - so why
IBus should be the only possible option?

Let's have defaul solution - the best point of compromise between
language support, UX, developers attitude to GNOME etc etc. But let's
not make it the only possible solution.

I hope noone is going to fallback to the worst possible argument it
is FOSS, you can always patch it - I would consider it as some kind
of Godwin law for FOSS architectures.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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 to the perfect IM integrated into GNOME. That task
needs a lot of input from the people of those nations. But that
discussion, ideally, should not mention existing IM frameworks.
Functionality, not names. Otherwise it will be endless IM1 is better
than IM2 for language L1, while IM2 is better than IM1 for language
L2 flamewar.

The second direction - from the architectural POV: what would be the
interface that could allow any slightly less than perfect IM (or
multiple IMs - if it is possible) to be integrated into GNOME.
Perhaps, that part can be discussed even by people without immediate
IM experience - just knowing what Gtk/Gnome-control-center/... can and
cannot do. And looking at the requirements and ideas expressed by the
first table.

After that, there could be fair competition among IM solutions.

Yes, there can be another approach, which I guess is the worst of all
(but still some people like it, I know) - pick one existing IM
framework, make it hard dependency, and start fixing its bugs, without
giving alternatives any chance...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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 and xmodmap. Perhaps it did not
work quite well, but that was the idea. Is there any chance to create
some kind of abstraction layer (dbus interface?) that would put IM
frameworks on equal grounds (subject to discussion - should it be
runtime or compile time choice). Would it be possible from gtk POV?
g-c-c and g-s-d POV?

Additionally, would the people using various IM frameworks be able to
create some kind of comparison table on l.g.o?

Personally I am not using IM, so cannot be expert of any kind in that
area... I only dealt with XKB so far.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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 need changes, as you for
 example will be compiling 5 groups instead of 4, but what I'm mostly
 concerned with it is not adding more protocol, so that applications
 (as opposed to session components) will work without changes.
Since the bottom of that issue is x server - I guess would be useful
to draft the todo list for it. So other libs would propagate that
solution up the stack.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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 survey as well.
Also, the groups nbsp:* and euro:* are probably applicable (well, I
would not insist on those two - but it is just IMHO).

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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 options dialogue, with conflicting options[1],
 we have a X server imposed 4 layouts maximum limit[2], server-driven
 keyboard shortcuts with limited options[3].
That's XKB world, right. Something should be done to hide its
oddities, as everyone agrees. All I am saying is that riches and
flexibility of XKB world should not be lost, if possible. A couple of
notes: [1]I am not sure which options are conflicting? [2]As I said
earlier, there can be workaround. Not perfect, but the best you can
do... [3]You cannot avoid that if you deal with server-based group
switching. Well, if you move group switching to the client side, you
can do everything of course...

 We also lacking integration with input methods that a large number of
 users use (and if you want to compare those things, much larger than the
 number of people that use per window layouts).
+100500.

 There will be small regressions, which we'll do our best to fix, and
 there will be design decisions made to ignore particular problems and
 settings (because I don't see CapsLock key placement as a requirement to
 the free desktop).
Filtering out some options/group is reasonable, even necessary - but
if you are going to keep some of them visible anyway - let's allow
people to turn the filter on/off. Costs nearly nothing, decreases the
unhappiness of the advanced users.

 We need to go forward (and you're merely pointing to problems that we
 didn't know existed because code isn't implemented yet!). I'm sure we'll
 sort those problems out in due time.
Agree!

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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 effectively invalidates any
surveys among existing user base. How are you going to get the
feedback then? I guess the good intentions of the usability
specialists and designers are not enough, without reality checks,
right?

Could GNOME perform a real review on the XKB option groups - find out
which ones are used, which ones are not? Of course, it would be
difficult to eliminate the bias to geekness - but that's what GNOME
user base is.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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 is even worse than making
decisions based on Google+ surveys.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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 Compose to Menu, Capslock...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

Thank you Allan. It is always good to see that GNOME decision makers
listen to users, really!

Could you please list the options/groups that are currently going to
be hidden as exotic/geekish?

And, did you think about setting up the formal survey? Your idea to
ask people was really good!

On Wed, 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 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 Compose to Menu, Capslock...

 Apologies, that page is a little out of date (my bad). We're currently
 aiming to have the compose key shortcut in the keyboard preferences,
 at least to begin with.

 I'm still keen to prioritise the 3rd level chooser, but I think we
 should probably move one step at a time.

 Allan
 --
 IRC:  aday on irc.gnome.org
 Blog: http://afaikblog.wordpress.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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?

 Taken to the extreme, as an example you'll be familiar with: if you
Obviously, your survey results are only as good as your survey
environment and audience. Does that mean that any effort in futile?

 So any survey is likely to be biased, which makes surveys not so useful.
Sorry, I do not quite understand that remark. Are you saying there is
no way to find the audience that would be unbiased? Are you just
implying that the current userbase of GNOME is so geekish that fair
survey among existing users would only represent the POV of geeks?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

        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
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

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 runtime won't be picked up...
My question was about layouts that are implemented through ibus, but
not xkb. For example, if user chosen Chinese IBus layout - what's
going to be entered into xterm? Will XKB layout be converted on the
fly from IBus layout?

 That said, it's my understanding that the IBus developers have a way
 to workaround that problem with the XKB simple engines for IBus which
 should basically allow us to always direct these legacy apps to use
 IBus for input and then IBus will just forward the symbols it gets
 from the key press events unmodified.
Err, I am not sure I understand the process completely. Does that mean
IBus sets up some proxy that converts X events before they reach
xterm?

 The layout is switched at the X server level. The code I have now is
 doing the equivalent of running setxkbmap layout whenever the user
 triggers a switch. I don't think network transparency is hindered in
 any way here.
Ok, that's fair. Except for pure IBus layouts - they cannot be
configured using setxkbmap, right? And, of course, there is a question
of performance - invoking setxkbmap (even calling corresponding XKB
APIs) is so much more expensive than changing current group in X
server...

 Right, no. The keyboard layout previews I'm planning to do by just
 calling the gkbd-keyboard-display utility from libgnomekbd so there's
 still a runtime dependency on it for this specific tool.
Fine.

 I don't think we'll need to read the xml registry for anything at this
 point. But if the need arises I'll probably just use libxklavier for
 that of course.
How are you going to find out what layout are available from XKB?

 And maintain a table of XKB layouts and IBus engines that each of
 those entries translates to. The user won't be faced with arbitrary
 choices of layouts, variants, options or IBus engines. We will provide
 what's most sensible.
I am opposite to that. If the user adds layout/variants to
xkeyboard-config, he wants these layouts to be available. I already
have bug reports about not showing extra (more exotic) layouts - but
at least that is switchable with a single gsettings key. I am trying
to be sensible in separating core from extras - but at least if
something managed to get into core - it is visible immediately.
Neither libxklavier nor libgnomekbd nor g-c-c filters those materials
- all filtering is done in xkeyboard-config (and it is easy to switch
on/off). By putting extra filter, you make the process more difficult
- people will have to change two places, xkeyboard-config and your
code (will it be compiled-in or put into some xml file?). The process
becomes not transparent.

 if you just run setxkbmap -option compose:ralt on a session startup
 script we won't undo that even if you are switching layouts during
 that session.
So, even if the user would tweak the options using GUI - you keep the
options specified with setxkbmap at startup, right? Even if the user
unchecks/checks compose:ralt checkbox?

Regards,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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 well be!). The user would not be
able to choose the XKB one, effectively damaging its experience
outside of IBus world, right?

 Well, if you're running GNOME 3 I'd say your computer can certainly handle 
 that.
Fair enough.. Well just keeping in mind that the performance degrades
gradually:) Seriously, there can be an issue if you implement layout
per window option and people would expect alt-tab to work
instantly... People sometimes encounter race conditions even when only
group is switched. And you are going to setxkbmap on every alt-tab
(the option layout per window is must have).

 These aren't changing every month are they? Every once in a couple of
 years? I think we can just maintain a list of what's useful on the
 GNOME side.
base.xml.in changes much more frequently than once a couple of years:
http://cgit.freedesktop.org/xkeyboard-config/log/rules/base.xml.in

 Honestly, if a user is locally editing stuff under /usr/share/X11/xkb,
 is he our target user? Remember that what I'm trying to do here is
 keyboard input configuration be hassle free.
Err, if we put XKB options aside, I do not quite see why the current
search-based way is not hassle-free. Well, yes, having IBus and XKB
separated is confusing, I admit.

 There's no compose:ralt checkbox at the moment. If it's deemed
 necessary we will add one (certainly not with that name) and we will
 override that specific option then.
There should be the option (ok, hidden in gsettings): show me all XKB
layouts/variants, show me all XKB options! Effectively turning 2ndary
IBus filter off. That would make everybody happy. But in order to
implement it, you need to parse base.xml ;)

Cheers,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov]

 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 degrades gradually?
I just meant that one this solution may be safe enough, but every time
you should understand that there will be another one... and another
one... One day you find your system is too slow.
The concerns of Owen are really more important, valid and substantial.
So, I guess it is a bit early to forget about group switching
altogether.

 (the option layout per window is must have).
 Why is it a must have? I don't think it makes much sense actually.
It IS must have. A lot of people I know are using it. If I type in
Russian in my libreoffice, then switch to Firefox and use American
layout - I want the Russian layout to be restored once I switched back
to libreoffice. That is important feature, and I am going to support
the wrath of all angry users if you lose it.

 I meant changing as in addition of new layouts. Bug fixes, sure,
 we'll get those whenever a new version of xkeyboard-config is
 released.
Errr, those bug fixes are in most cases adding new layouts/variants/options.

 Right, I was thinking of IBus users there. There's no reason they
 should be 2nd class citizens.
Absolutely no reason. But there is no reason why XKB users should
suddenly become 2nd class when they were reasonably happy with the
existing infrastructure. Would you agree? By unconditionally enforcing
the united kbd management on them, you are doing exactly that.

 I don't agree. If you know about all that stuff you can just as well
 configure everything yourself outside of GNOME and disable the
 keyboard g-s-d plugin.
Well, that argument can go a very long way, down to twm environment,
right? XKB is fully supported by GNOME till 3.4 - why do you insist on
breaking that? Can the integration be done without destroying of what
GNOME already has in place? Yes, for usability sake we could hide
under the carpet the technical difference between IBus and XKB. But
make it accessible still.

IBus runs on top of XKB. Let average user experience the unified
image of the keyboard world, that is the best approach. Most probably
- with the single list of layouts etc. But if the user wants the
truth, just pure power of XKB, and full xkeyboard-config layout
database - give it to him... It does not cost much - because it is
already there! Just do not break it, build on top of it please.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Request: bump libxklavier dependency for libgnomekbd

[Sergey Udaltsov]

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.
 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?

 No complains, so libxklavier 5.2 is available in the modulesets now

 Regards

 --
 Javier Jardón Cabezas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Request: bump libxklavier dependency for libgnomekbd

[Sergey Udaltsov]

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
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v6)

[Sergey Udaltsov]

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 (unfalsifiable), regardless?

Sergey
On Oct 18, 2011 5:03 p.m., Jasper St. Pierre jstpie...@mecheye.net
wrote:

 It's useless to me because there's nothing actionable there. The
 survey results don't give us anything to do except die in a fire.
 --
   Jasper
 ___
 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: GNOME user survey 2011 (v6)

[Sergey Udaltsov]

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: 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 (unfalsifiable), regardless?

 How are those two things even connected? How could switching the
 development emphasis to work on obsolete technologies help anybody at
 all (users/developers/designers and so on)?

 Cosimo


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v6)

[Sergey Udaltsov]

 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 those goals.

 Phoronix is a tabloid seeking sensation.
Agree. But I guess it is not a surprise that some users are crying for good
old gnome2. If gnome could properly estimate the share of those deprived...
would it change anything?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v6)

[Sergey Udaltsov]

 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
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v6)

[Sergey Udaltsov]

 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 don't
 stay with what works for them?
People upgrade distros. They upgrade HW. Would you advise people who
love WinXP and hate Vista(ot Win7) stay with WinXP - considering that
it has issues with new HW?

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v6)

[Sergey Udaltsov]

 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 occuse people making decisions. You'll just alienate
them.
What I initially asked - and still did not get the answer - what could be
the format of the feedback that could change the policies. Perhaps reverting
some of them. What kind of critical feedback would not be treated as
useless?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.2 Blocker Report for week 35

[Sergey Udaltsov]

 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
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Sergey Udaltsov]

 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 is Linux, but it
can be Solaris or *BSD). DE != OS. And the system can be multiuser -
which sometimes means both KDE and GNOME can be present in the same
installation. Also, some, especially semi-professional apps are not
going to be duplicated in both environments (I am not talking about
text editors or calculators) - so there are relatively high chances
that the user would need both sets of settings, for KDE and GNOME (in
that sense having ShowOnlyIn can be a bad idea - some foreign apps
would become not configurable).

The best idea really would be to define the mechanism of feeding the
settings into foreign apps. Both directions, GNOME (desktop) -KDE
(apps) and KDE (desktop) - GNOME (apps). If we have that, in addition
to ShowOnlyIn, user could never notice that the system has two
variants of System Settings. The only problem with that approach is
that some settings can be defined only in one DE. In that case, sane
default values could be the only choice..

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: systemd as external dependency

[Sergey Udaltsov]

 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 least, we should.
Thank you Vincent, that is sooo true.

Even from technical POV, could please someone explain - why cannot
GNOME define some reasonable cross-desktop dbus interface (not tied to
particular internals of systemd), standardize it on fd.o, provide
single implementation (in systemd) and let other OSes care about
themselves - in _friendly_ manner, as you Vincent say? If that
interface is well designed - I do not think it would be hard for
others to implement it. Why introduce hard dependency on the daemon
which is not a total standard even in Linux world?

The whole concept about GNOME OS seems to be more dangerous than
useful... This idea comes up every time GNOME wants to alienate
somebody or something.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: systemd as external dependency

[Sergey Udaltsov]

 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 contraire, I'd guess you'd waste even more resources with
 dlopen() and friends.
Can all those services be standardized using DBus interfaces (DBus
activation if necessary)? IMHO that's the only way to remain friendly
to non-linux OSes, not having any bits of systemd (or distros that are
not using it)?

Sergey
___
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]

[Sergey Udaltsov]

 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 - gnome FAILED the main
goal - to define the final experience. And that failure was unevitable. So
closing apis is just a form of avoiding responsibility for the failure.

 I dislike that
 I have a Mandriva control center.
It is unevitable with the current approach umho.
___
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]

[Sergey Udaltsov]

 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]

[Sergey Udaltsov]

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
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Sergey Udaltsov]

 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 friendship is that?? You force downstream to do things upstream
or suffer patching. You are taking the freedom to extend comfortably - the
freedom that existed in gnome2. Friendship?

 Calling it a failure is premature.
It is a failure from the start, because distros will be patching. They will
define the final experience, not gnome. End-users almost never use vanilla
gnome. They never will, distros will patch.

 But we're changing our approach. We want people to suggest their needs
 at GNOME, then we'll see how we can solve their issues.
That's what you want. Do distros want the same? Do 3rd party appdevs want
the same? Or do you just not care?

Sergey
___
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]

[Sergey Udaltsov]

 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.
Technically, if the architecture only allows extension through
patching (instead of extension points), it means the architecture is
closed (that must be a highly offensive statement, if we're talking
about free software). Also, that is a very effective way to alienate
3rd parties (app developers, distromakers). I suspect, that attitude
in gnome possibly affected Canonical decision to drop gnome 3. I would
not be surprised if other distros follow that example. First
_unfriendly_ move from GNOME side: distros have to either patch g-c-c
to introduce distro-specific capplets (maintaining patches is not the
same thing as maintaining separate modules using relatively stable
APIs) or invent their own settings mgmt frameworks. If some distro
chooses the 2nd way - why stop? Next step - move all things to shiny
new distro-specific config UI, then - replace gnome-shell. Good bye,
GNOME3!

GNOME is not an OS. GNOME is not a distribution. GNOME is a core
desktop (desktop building toolkit, if you like) that is used by
distributions - it is them who define the _final_ user experience. Do
we all agree that GNOME should be distribution-friendly, that GNOME
should trust distributions, make their life reasonably comfortable? So
let them put the configuration for the drivers, for the system
services, if they like, etc into g-c-c. Let them = make it
reasonably comfortable = use APIs, not patching. If we do not trust
distributions ... we have to change a lot of things in GNOME, starting
from the first letter of the name (back at the days of GNOME 1 G was
for GNU)

All those rants aside, let me ask one question: is this APIlessness
considered as a temporary measure (I know, gnome 3 is currently highly
undocumented - at least I did not see g-c-c 3 UI guidelines) for some
transitional period or is it a policy that is planned to last in
foreseeble future of gnome3?

Sergey
___
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 Re: GNOME Feature Proposal: Backup]

[Sergey Udaltsov]

 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 moblin, MeeGo, Maemo, etc will end up redoing the preferences
 from scratch, rather than building on the gnomecc work.

 They are doing that anyway, and there is nothing we can do to stop them.
Why are they doing that? Isn't that a very important question? Is just
just because of them - or is it about GNOME as well?
If distros tend to ignore the things that GNOME provides - perhaps,
GNOME provides something that is not easy to use/customize?

Sergey
___
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]

[Sergey Udaltsov]

 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 side-effect of the license. It's not the major point
 of the project.
My whole point was that in the ideal world GNOME could be extensible
enough so that no _forking_ would be necessary. Extension modules, not
patches. That would be not a side effect of the license but the
fundamental feature of the architecture. Do you see the difference?

Well, anyway, there are other people who drive the project. I just
think it would be fair if GNOME could make some official statement on
extensibility policy. That question was already asked in that thread,
before my intervention. That probably is worth a page on
live.gnome.org

Sergey
___
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]

[Sergey Udaltsov]

 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 interesting and insightful info. The question
is - could (or would) GNOME do something to avoid that situation with
distros?
g-c-c could be for linux what system preferences are for macos or
control panel for windows - configuring every aspect of OS except
configs of desktop apps (but including system configs, server apps
config etc). Well, if gnome does not want it, let it be so. I am just
kindly asking to put together some kind of policy document about all
those things. Is that a reasonable and constructive request?

Sergey
___
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]

[Sergey Udaltsov]

 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, maybe we
 need to use a bigger stick to make them work upstream.
Well, their own panels might control things that are not related to
the desktop as such. I do not think anyone in gnome would welcome
those things upstream...

 But that way you end up with useless things like a Java Control
 Panel or httpd Control Panel [1] and other non-sense that you see
 on Windows (and OS X for that matter - it's just that people don't
 install much 3rd party crap there).
Right, httpd control panel is basically one example of what redhat's
system-config-* tools are doing.

 an fancy editor for /etc/httpd/conf/httpd.conf - it's a completely
 inappropriate app because if you know what httpd is, you really don't
 want to click GUI buttons - you want to edit the config file with
 vi(1) or whatever your editor of choice is. Same goes for a lot of
 other distro-specific config tools created because we need a GUI
 without really thinking whether it was a good idea. /rant
Err... Personally I always thought that the area where IIS was way
ahead of httpd is the GUI configuration tools nicely integrated into
system configuration GUIs.

 Not sure we need to be all lawyerish about it and write policy
 documents and whatnot - I'd rather people spend time on writing
 awesome code and doing awesome designs. All in the same sandbox :-)
Well, it is not about law - it would just indicate that people should
not even bother using temporary public APIs that might occationally
(for some tactical reason) be provided. That would explain that the
only way to keep long-term health relations with GNOME as upstream is
do to THESE things and not to do THOSE things. Helpful strategy hints.

 And, FWIW, I'm just expressing my personal opinion about GNOME and
 nothing I'm saying here is authoritative. It could be that the
 gnome-control-center maintainers and others have other views about it.
Sure. But according to this thread, your opinion is very similar to
the ideas expressed by many others, including g-c-c drivers. Thank you
for explaining things.
___
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]

[Sergey Udaltsov]

 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. But that dictate may kill gnome publicly - if
distros would not want to be dictated.
Back into the history, X11 provided mechanism, not policy. GNOME
enforces policies. Fine, but let's not go too far with this dictate.

And anyway, even if we dictate policies - at least we should have
courtesy to put them in words, I guess.

 But it seems by now we are a small minority :-|
Seem so.

 May I add: who is in charge to settle those _technical_ and _political_
 sides of GNOME Desktop development? ;-)
Very good question, actually.
___
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]

[Sergey Udaltsov]

 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
dictate is. Or did I misunderstand some statements? In a way, even HIG
itself is a dictate - a relatively weak form of it (but at least put
into the document, which is the best thing about HIG!)
___
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]

[Sergey Udaltsov]

 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
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]

[Sergey Udaltsov]

 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 like it's just a
 factory spitting out technology, at your bidding, that you can put
 together as you see fit. And then not giving any credit or
 contributing your changes back upstream. Think about it.
I totally support that idea. That collaboration should be mutual - or
it just would not work.
___
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]

[Sergey Udaltsov]

 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 be put together and explained. That document would have
some more or less formal status of policy, so it could be referenced.
Entitled GNOME-to-distribution interaction policies and guidelines
or smth...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

version requirement request: libxklavier 5.1

[Sergey Udaltsov]

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 moment, jhbuild is fixed (thanks to Luka Ferretti) to use
libxklavier from CVS

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

RFC : gnome and non-linux oses

[Sergey Udaltsov]

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 non-linux platforms?
If some UI is harmless but gives little functionality on linux and really
useful on other oses - should it be kept?

I am not fighting for a single button (I like it when code is removed) - I
am asking to provide guidelines, to avoid confusion in future.

Thank you,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: RFC : gnome and non-linux oses

[Sergey Udaltsov]

 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 from, say, Oracle engineers about
Solaris would be useful here. Or from FreeBSD ppl.

 In this particular case, I think it's a non-problem, and I'd rather
 remove it and get complaints afterwards rather than preach for the
 status quo, knowing full well that the setting will be useless and
 potentially confusing for a majority of users.
As I said before, I am not really defending the status quo in relation
to xkb model - and from some point of view I like it when the code and
UI is simplified. I am asking the people's opinion about the general
strategy in treating non-linux systems. Or, perhaps, officially
admitting that we do not have a policy here - just decide on
case-by-case basis.

Cheers,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Sergey Udaltsov]

 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 standards (to NETWM and beyond) so that
people could use different WMs? Is it the same GNOME that helped to
establish freedesktop.org with all those cross-DE standards? Are you
implicitly saying that GNOME does not believe in cross-DE standards anymore?
GNOME already effectively dropped cross-DE systray, right? Now, WM mobility
is gone. What's next, dare I ask?

I feel somewhat uncomfortable to tell you that, but people invented
standards exactly for that purpose - not to test everything with everything,
but just to make sure things work together because they follow standards.
And, if X does not work with Y - it is either because X does not follow
standard S, or Y does not follow it - or there is some gap in S that can
(and should) be fixed. That's the way things always worked in Unix world,
that what makes unix great, what makes freedesktop.org important (perhaps
even more important than GNOME, from some POV).

One of the strongest selling points of Linux desktop was the freedom of
choice. Not only DE1 or DE2 but component1 or component2. While GNOME2
provided reasonably consistent experience out of the box, it allowed people
to change things as they wanted - and it was reasonably simple (no patching,
thanks). For example, many users would just throw GNOME out of the window if
that window could not be managed by their favorite tiling window manager.

I realize that at this stage GNOME3 (3.0) is not going to be flexible in
this aspect. Not enough resources and such. But perhaps GNOME could admit
that was a mistake - and express the intension to fix it in 3.2/3.4/... Now
that nearly everybody is agree that applets are useful and would be nice to
have around, perhaps the position on the WM could be adjusted somehow as
well?

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Sergey Udaltsov]

 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 particular wm? Perhaps, those features could be published,
standardized so other wms could follow? Just like netwm...

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Sergey Udaltsov]

 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?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Sergey Udaltsov]

 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
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Sergey Udaltsov]

 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 would say it's
 somewhere between 5 and 10%. Maybe I'm wrong, but 1% is wrong, too.
Well, now that people are throwing percents at each other, it is a
very interesting point as such - does anybody know anything about
userbase whose experience GNOME3 is going to improve? I am not
ranting/trolling here, I am really interested. Was there any research
made? I realize that my references to voting on linux.org.ru cannot be
seriously considered - but perhaps someone made serious usability
testing or survey, someone could say XX% are not happy, YY% are not
happy with GNOME2 (of course, ZZ% do not care at all or not using
gnome), the first figure is going to increase with GNOME3 to XY%, the
second will drop as low as YX%? That kind of research, if properly
made, is usually a conclusive argument for/against any serious visible
design changes.

I hope that GNOME3 is not just a leap of faith...

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Sergey Udaltsov]

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 multiple advantages to accommodating such users in fallback
   mode as well rather than telling them to use GNOME 2.
That sounds unbelievably correct!

    - We don't have to worry about parallel install issues for GNOME
      libraries.

    - It reduces pressure on us to provide support for old versions
      of GNOME.
Hear, hear!

  * If (*if*) it doesn't suck up a lot of developer time, I don't see any
   harm in continuing to provide gnome-applets. Yes, I suppose it could
   be considered weird if there's a way of adding a pair of eyes to
   the panel in fallback mode but not in the full GNOME 3 experience,
   but honestly, if something thinks that their day is not complete
   without a pair of eyes in their panel, I'd rather let them use
   fallback mode than argue with them that they are wrong.
I know exactly who you're talking about:)

Thanks again, I really hope the release team would consider your
opinion seriously.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Sergey Udaltsov]

 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 gnome-applets compatible with upgraded
gnome-panel - but gnome 3 is not going to include them regardless.
Did I get it wrong? I am not saying I am ready to build them - but
that denial position is a barrier for anyone to step up - because it
would be a personal hack project, nothing more. If gnome 3 is ready
to accept gnome-applets (uplifted to new APIs) - that could encourage
somebody.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Re: gnome-panel gnome-applets?

[Sergey Udaltsov]

 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 someone interested) - and GNOME is
going to provide them with just crooks, not a real solution. I am sure
one of the most important reasons people choose GNOME2 compatibility
mode is the applets (I guess noone thinks that gnome-panel itself is
so attractive that people cannot live without it). To be honest, not
them, us - because personally I am going to stay in that mode as
long as possible, so I really would like to have it working.

IIRC for a moment, gnome-shell does not provide extension
architecture, similar to applets - so if a person wants something
custom (not notification, not status) - where would he go?

About gnome-shell compatibility. I tried to run gnome-shell inside
vmware workstation. No way. There is no 3d there.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Re: gnome-panel gnome-applets?

[Sergey Udaltsov]

 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 from upgrading their
distros, unless the distro choses to support both gnome2 and gnome3 -
which I'm afraid will not be the case for most of them. To be fair,
gnome2+3 maintenance may be not trivial, at least GNOME does not
bother separating binaries by name.


Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Re: gnome-panel gnome-applets?

[Sergey Udaltsov]

 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 indication of a problem in gnome3 architecture? Is it simpler to
maintain extra modules than to scale mutter and gnome-shell down? Especially
considering that fallback mode would be somewhat weak, functionally

 BTW, nobody forbids you to create a gnome-sergeys-applets module that is
compatible with the GNOME3 gnome-panel and ships all the applets you want.
But it will just not be part of the default moduleset.
Sure, but that policy is not friendly to existing users.

Sergey, who sometimes prefers to look backwards rather than forward
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Re: gnome-panel gnome-applets?

[Sergey Udaltsov]

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 and simple panel, as William mentioned
5. No fallback at all.

Anything I missed? Was that choice discussed anywhere?

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-panel gnome-applets?

[Sergey Udaltsov]

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, gnome-applets are gone. Is this planned? Who'd need the
panel without the applets?

Cheers,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome2 and gnome3: strategy of coexisting

[Sergey Udaltsov]

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 of packages (two entries in gdm sessions list). So,
is gnome going to address that - or just leave it to distromakers? Of
course, we know distromakers are creative, they'll go for something
like /opt/gnome3 and /opt/gnome2, tweaking PATH etc etc - but every
distro is going to do that differently. Are we happy about that - or
perhaps we could make their life easier by introducing some
recommendations, conventions? Resolving that issue could also help
developers to live in stable gnome2 while doing things for gnome3.

I will narrow my question a bit. Some components, like gnome-session,
gnome-settings-daemon etc for a moment are using same names as they
did in gnome2. Would it make sense resolve that collision by using
different names (most simple way - adding 3 add the end)? I am not
concerned about creating a bad practice here: gnome2 was evolving for
decade, and I hope gnome3 would be around for another decade (and who
knows - will gnome4 ever exist?;).

What do you think? Does my question make any sense at least?

Thanks,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome2 and gnome3: strategy of coexisting

[Sergey Udaltsov]

Thanks for the answer. So, does that mean we directly or indirectly
recommend to distromakers NOT to allow users to choose between gnome2
(real, not (panel + nautilus)/gnome3) and gnome3 sessions? Does
that mean we recommend not to bother creating two sets of packages? Or
we are just neutral 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 and gnome3 on the
 same system?

 Short answer is no, and we won't be doing it.

 I will narrow my question a bit. Some components, like gnome-session,
 gnome-settings-daemon etc for a moment are using same names as they
 did in gnome2. Would it make sense resolve that collision by using
 different names (most simple way - adding 3 add the end)? I am not
 concerned about creating a bad practice here: gnome2 was evolving for
 decade, and I hope gnome3 would be around for another decade (and who
 knows - will gnome4 ever exist?;).

 What do you think? Does my question make any sense at least?

 When people talk about Classic GNOME wrt GNOME 3, they mean the ported
 to GTK+ 3.x, updated to GSettings, parts of the GNOME 2.x experience.

 There are no plans to make gnome-settings-daemon, bits of the
 control-center, and whatever else core components of the desktop
 parallel installable.

 The libraries will be parallel installable so you can run your
 not-ported-yet applications, but core parts of the desktop won't be one
 of them.

 Cheers


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome2 and gnome3: strategy of coexisting

[Sergey Udaltsov]

Personally, I feel that is wrong - that kind of attitude to 2.x. It is
(not was!) a stable and solid foundation. While we are floating into
new and dangerous waters of 3.x (still risking getting into the
situation KDE folks had: KDE 4.0 != KDE4), at least we could make a
couple of small things here and there - allowing them to coexist, for
smoother transition. I know that is always a question of resources, as
usual - but if some things cost nothing, why not buy them?

Sergey

PS I am already missing 2.x. That's just my conservatism - but I know
a lot of users are like me. People like me 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 that mean we directly or indirectly
 recommend to distromakers NOT to allow users to choose between gnome2
 (real, not (panel + nautilus)/gnome3) and gnome3 sessions? Does
 that mean we recommend not to bother creating two sets of packages? Or
 we are just neutral and do not care (and we do not help)?

 I don't expect anyone @ GNOME to care about 2.x. Distributions can do
 what they want, but need to take that into account.

 --
 Regards,
 Olav

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Label in tray = P in the A

[Sergey Udaltsov]

I released 2.30 and committed the latest changes to git. The current
solution is to use the same font as application menu but the glyphs
are somewhat stretched horizontally, to guarantee the squareness. It
does not look too bad for me. I'd appreciate if someone try
libgnomekbd from git and comment.

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?

 No, your three-letter acronyms, like USA or RUS


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Label in tray = P in the A

[Sergey Udaltsov]

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
 I will check the snapshot function...

 Use pango_cairo_context_set_font_options() with the cairo_font_options_t
 retrieved from gdk.

 behdad

 Sergey

 On 3/24/10, Matthias Clasen matthias.cla...@gmail.com wrote:
 On Tue, Mar 23, 2010 at 7:42 PM, Sergey Udaltsov
  sergey.udalt...@gmail.com wrote:
   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, sets status icon from
   pixbuf. Worst of all, the widget has to follow gtk style, font
   rendering settings etc. What a pain.. Bug reports... Now, another one:
   https://bugzilla.gnome.org/show_bug.cgi?id=611875.
  
   Here is my question of the day: why does the font size retrieved from
   gtk style and provided to cairo give different results, comparing to
   the gtk itself? I simply do not get that...
  
   I tried to use cairo_scaled_font_t - but the results are even worse,
   the font gets smaller;)
  
   Thanks for any ideas,


 Using the cairo 'toy' text api is almost never correct. I've just
  fixed a bunch of Indic text rendering bugs in various apps that were
  caused by use of this api instead of pango. You can have a look at
  pango/examples/cairosimple.c for how that might look.
  Or maybe you can just use gtk_widget_get_snapshot with a label widget.

 ___
 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: Label in tray = P in the A

[Sergey Udaltsov]

Thanks lads, the idea about pango really worked. I should not have
used the 'toy' API. But the things got worse with the proper size -
the label becomes wide.

Here's another trouble. GtkStatusIcon makes the icon square.
Effectively, it means the image gets scaled and the glyphs become
narrow. 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, 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
 I will check the snapshot function...

 Use pango_cairo_context_set_font_options() with the cairo_font_options_t
 retrieved from gdk.

 behdad

 Sergey

 On 3/24/10, Matthias Clasen matthias.cla...@gmail.com wrote:
 On Tue, Mar 23, 2010 at 7:42 PM, Sergey Udaltsov
  sergey.udalt...@gmail.com wrote:
   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, sets status icon from
   pixbuf. Worst of all, the widget has to follow gtk style, font
   rendering settings etc. What a pain.. Bug reports... Now, another one:
   https://bugzilla.gnome.org/show_bug.cgi?id=611875.
  
   Here is my question of the day: why does the font size retrieved from
   gtk style and provided to cairo give different results, comparing to
   the gtk itself? I simply do not get that...
  
   I tried to use cairo_scaled_font_t - but the results are even worse,
   the font gets smaller;)
  
   Thanks for any ideas,


 Using the cairo 'toy' text api is almost never correct. I've just
  fixed a bunch of Indic text rendering bugs in various apps that were
  caused by use of this api instead of pango. You can have a look at
  pango/examples/cairosimple.c for how that might look.
  Or maybe you can just use gtk_widget_get_snapshot with a label widget.

 ___
 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: Label in tray = P in the A

[Sergey Udaltsov]

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 about pango really worked. I should not have
 used the 'toy' API. But the things got worse with the proper size -
 the label becomes wide.

 Here's another trouble. GtkStatusIcon makes the icon square.
 Effectively, it means the image gets scaled and the glyphs become
 narrow. 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.

 Just use a keyboard icon, and have a menu to switch layouts.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Label in tray = P in the A

[Sergey Udaltsov]

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 wrote:
 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 about pango really worked. I should not have
 used the 'toy' API. But the things got worse with the proper size -
 the label becomes wide.

 Here's another trouble. GtkStatusIcon makes the icon square.
 Effectively, it means the image gets scaled and the glyphs become
 narrow. 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.

 Just use a keyboard icon, and have a menu to switch layouts.



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Label in tray = P in the A

[Sergey Udaltsov]

I can fit indeed.
The only thing is that the resulting font would be different from the
font used in the menu. I do not see any other solution either, to be
true...

Sergey

On Wed, Mar 24, 2010 at 2:18 PM, Milan Bouchet-Valat nalimi...@club.fr wrote:
 Le mercredi 24 mars 2010 à 14:17 +, 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



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Label in tray = P in the A

[Sergey Udaltsov]

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, 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.

 Yeah, something like that.  Measure size, cairo_scale, redraw.  May need to do
 two / three times to get the best fit.

 b

 Regards

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Label in tray = P in the A

[Sergey Udaltsov]

Ghm, what is overlay? The tooltip? Again, too bad. The indicator
should work without mouse pointer.

The tooltip is useless only for USA - for Russia, the letters are
'Rus' and the tooltip is 'Russia'. Same for other countries.

Sergey

On Wed, Mar 24, 2010 at 2:38 PM, Matthias Clasen
matthias.cla...@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 A without further explanation sit between my status
 icons is kinda odd in the first place... also, repeating the same
 three letters in the tooltip is pointless.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Label in tray = P in the A

[Sergey Udaltsov]

 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
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Label in tray = P in the A

[Sergey Udaltsov]

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 it in the icon, like an emblem.
 What kind of emblems? For example for Usa and Russia?

 No, your three-letter acronyms, like USA or RUS

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Label in tray = P in the A

[Sergey Udaltsov]

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:
 Translated. Typically, 3 letters (well, at least that's my
 recommendation as maintainer of xkeyboard-config).

 About this, a quick note about xkeyboard-config I always forgot to
 report. Why don't use directly ISO 3166-1 alpha-3[1]?

 As Italian translator of xkeyboard-config, I've to say it's a little
 mess to check where a 3 letter message come from. Currently the 3 letter
 letter code for many countries seems to use the ISO spec, but some
 countries have a custom code: for example Bangladesh is Ban while the
 ISO code is BGD, same for Bhutan (Bhu instead BTN) or Greece (Gre
 instead GRC) and maybe others.

 Using directly uppercase ISO would help translators and users, allowing
 to have unique 3 letter codes for each country with no cost (translators
 could simply copy original message to translated message, if no
 transliteration in needed).

 [1] http://en.wikipedia.org/wiki/ISO_3166-1_alpha-3


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Label in tray = P in the A

[Sergey Udaltsov]

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, sets status icon from
pixbuf. Worst of all, the widget has to follow gtk style, font
rendering settings etc. What a pain.. Bug reports... Now, another one:
https://bugzilla.gnome.org/show_bug.cgi?id=611875.

Here is my question of the day: why does the font size retrieved from
gtk style and provided to cairo give different results, comparing to
the gtk itself? I simply do not get that...

I tried to use cairo_scaled_font_t - but the results are even worse,
the font gets smaller;)

Thanks for any ideas,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Sergey Udaltsov]

 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 n810) etc.

 tbh I'd find it quite useful if we could run samba from inside a user
 session too, the same way we can run apache in it for gnome-user-share.
I am quite happy that samba does not provide that feature (I suspect
there might be some issue with sharing tcp ports). There is no need to
create many processes where one process can do everything. Think
Occam's razor;)

 It would be kinda weird if a system Rygel would share the audio streams
 of a user PulseAudio instance.
Why not? Is it a technical issue or architectural? Sorry, I am not
familiar with the PA internals, so some details would be nice to
have... Actually, it was already mentioned that Rygel can run as
system service - so I assume that feature is already available? Or
not?

 That sounds like a pretty weak argument, of the Unix nostalgia kind.
That is not an argument as such, I am just showing where I come from.
The primary values, so to say:) Yes, I like the true and proven ways
of good old Unix, and consider it architecturally suspicious where
people ignore them without very serious reason (well, at least I feel
obliged to question the reasons and challenge them:).

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Sergey Udaltsov]

  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 (personal computers, in the worst of all possible
interpretations - computer for one single user)? That is ok for
tablets, smartphones etc - but not for general purpose desktop.

If some computer provides media collection through UPnP/DAAP, it
should do it as a system-level service, just like mt-daapd (even
though it can be flexible enough to accomodate per-user dirs, just
like apache or smb).

Cheers,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Sergey Udaltsov]

   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.
That use case is perfectly served by samba - having ONE system-level
daemon and multiple per-user shared directories (controlled by users)

 We want *each* user to have full control of
 whether she wants UPnP services to be enabled or not and then which
 services exactly she wants and what exactly she wants from it using a
 simple preferences UI.
I do not see any trouble with that. That is absolutely valid
requirement - except I'd replace each user with each user belonging
to some group ;)

   Lets assume for a second that we want rygel to run as a
 system-service, how does rygel then communicate to processes running
 on session-bus (e.g tracker, rhythmbox, totem)?
AFAIK the typical model is working the other way around. If these
process have anything to say to system-level daemons, they initiate
communications. CMIIW. Why is that model bad for Rygel?

   Lastly, rygel can be run as both system-wide service and
 per-session at the same time on the same machine.
That is a very important thing to know. In that case, I still have a
couple of questions:
- Should gnome promote per-session usage of Rygel (in case of
adoption), as more desktop-oriented mode of operation - or should
gnome be neutral in that aspect?
- What's the general approach for system-wide services in gnome? Does
GNOME need that kind of policy?Some system-wide services are really
useful for desktop, would GNOME adopt them?

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Sergey Udaltsov]

Sorry for being unclear. Sure I know the difference between UPnP and
CIFS. I am just saying that approach (I incorrectly called it use
case) single system-level daemon + multiple user-controlled
user-specific resources looks architecturally better than multiple
user-level daemons.

Sergey

PS My 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 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.
 That use case is perfectly served by samba - having ONE system-level
 daemon and multiple per-user shared directories (controlled by users)

 I wasn't aware that my Bravia TV or Roku SoundBridge could play from
 CIFS shares, I thought they were DLNA players, but thanks for informing
 me of this fact.

 Yes, I'm being sarcastic.  Rygel is a DNLA media server, not a generic
 file server, samba doesn't perfectly serve the role of media server.

 Ross
 --
 Ross Burton                                 mail: r...@burtonini.com
                                          jabber: r...@burtonini.com
                                           www: http://burtonini.com

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: libxklavier: version bump to 5.0

[Sergey Udaltsov]

 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 probably I still need to learn how to make
rock-stable ABIs. Since the requirements to applications (g-s-d in
that case) change, I have to cater for new use cases... I realize that
breaking interfaces is a bad habit, so I am doing that only when I
have to.

At least I am trying to be disciplined with sonames, so if package
name includes major number (like they do in ubuntu, libxklavier15),
user can have 2 versions in one system (if it is not a case, please
tell me and we'll try to sort that out).

Regards,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

libxklavier: version bump to 5.0

[Sergey Udaltsov]

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 plugin).

Any objections?

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: external dependency libxklavier: request to bump the version

[Sergey Udaltsov]

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 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 API (can provide with more details, if someone needs).

 I will make sure libgnomekbd, gnome-control-center and
 gnome-settings-daemon are modified accordingly.

 Don't forget gnome-applets and gdm, which seem to be affected too.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

external dependency libxklavier: request to bump the version

[Sergey Udaltsov]

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 API (can provide with more details, if someone needs).

I will make sure libgnomekbd, gnome-control-center and
gnome-settings-daemon are modified accordingly.

Cheers,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnomethree: what about log4G?

[Sergey Udaltsov]

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 standardized as recommended solution? First of all, desktop daemons
like g-s-d, gconfd or gnome-sessions would be much easier to support.
Even front-end apps need logging every now and then. Of course,
logging cannot replace gdb, valgrind, wireshark. xev, xprop etc - but
in many situations it makes support soo much easier.

I know there is some rudimentary logging already, but it is neither
powerful nor flexible.

What do you think?

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

cgit annotate

[Sergey Udaltsov]

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

[Sergey Udaltsov]

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
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: new module proposal: notification-daemon+libnotify

[Sergey Udaltsov]

 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
error that might happen (well, under normal circumstances g-s-d is
100% silent, but you know that far-from-perfect world...). But it
could not be done without blessed dependency. g-s-d is complex enough
to be completely bug-free - but usually in case of g-s-d misbehaves it
is not easy to find out what exactly happened - partially, because we
do not have desktop-wide logging facilities. At least, using libnotify
could improve things a bit (keeping g-s-d independent from X at the
same time).

Cheers,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: External dep version bump: libxklavier to 3.6

[Sergey Udaltsov]

  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 in 3.6 - it is used
now in gnome-control-center trunk.

Cheers,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: External dependency, libxklavier: request for version change

[Sergey Udaltsov]

Hello Fryderyk

The soname was changed because one function was removed - it was
unnecessary and never used (to the best of my knowledge). But the
rules require changing soname when you do these things. Am I wrong?

Sergey

On Feb 7, 2008 6:14 AM, Fryderyk Dziarmagowski [EMAIL PROTECTED] wrote:
 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? No API changes were made, no changes in GNOME code are
  required.

 What is the purpose of soname change in this release?

 --
 Fryderyk Dziarmagowski

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

External dependency, libxklavier: request for version change

[Sergey Udaltsov]

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
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Input devices capplets

[Sergey Udaltsov]

 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 think so... I am just not sure people find things like
numpad-related options or CapsLock behaviour belonging to i18n.

Anyway, since now this is just a popup - it would be quite trivial to
move it into any capplet we'll find suitable.

Actually I was more thinking along the lines of the latest mockups:
http://ultimum-projekt.de/mockups/keyboard.html.

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Input devices capplets

[Sergey Udaltsov]

 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 of the groups provided in base.xml. The only
way to distinguish it is hardcode its id. Which does not sound great
to me... But the visible strings in this group - they are provided as
is, and I totaly against extracting the key names from them (BTW they
are localized).

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Input devices capplets

[Sergey Udaltsov]

 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
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Please include into 2.22: libnotify, notification daemon

[Sergey Udaltsov]

 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
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

libgnomekbd branched for 2.20

[Sergey Udaltsov]

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 3.2 to 3.4 (to be released soon).

Cheers,

Sergey
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list