hi, DeviceKit is marked 100% done https://fedoraproject.org/wiki/Releases/11/FeatureList https://fedoraproject.org/wiki/Features/DeviceKit
but the problem reported in https://bugzilla.redhat.com/show_bug.cgi?id=470592
is not solved I guess it's very simple, we just need to pass uf8 option because the kernel patch which used to do that by default is dropped
if we are still using hal I guess it would be a small change in some .fdi
I reported that bug against hal (in times of F10 rawhide) but in F11 we have DeviceKit on the stage so I guess somehow I should notify its developers and maintainers
should I edit the wiki to make it 99% and add a link to the rhbz
On Sun, Mar 8, 2009 at 6:06 PM, Muayyad AlSadi alsadi@gmail.com wrote:
hi, DeviceKit is marked 100% done https://fedoraproject.org/wiki/Releases/11/FeatureList https://fedoraproject.org/wiki/Features/DeviceKit
but the problem reported in https://bugzilla.redhat.com/show_bug.cgi?id=470592
is not solved I guess it's very simple, we just need to pass uf8 option because the kernel patch which used to do that by default is dropped
if we are still using hal I guess it would be a small change in some .fdi
I reported that bug against hal (in times of F10 rawhide) but in F11 we have DeviceKit on the stage so I guess somehow I should notify its developers and maintainers
should I edit the wiki to make it 99% and add a link to the rhbz
the bug is already marked as F11Blocker....
On Sun, 2009-03-08 at 19:06 +0200, Muayyad AlSadi wrote:
hi, DeviceKit is marked 100% done https://fedoraproject.org/wiki/Releases/11/FeatureList https://fedoraproject.org/wiki/Features/DeviceKit
All feature pages had to be at 100% last Tuesday, because that was the feature freeze...
should I edit the wiki to make it 99% and add a link to the rhbz
No, that is not the right thing to do. Just file a new bug, or clone the existing one.
On Sun, 2009-03-08 at 19:06 +0200, Muayyad AlSadi wrote:
I guess it's very simple, we just need to pass uf8 option because the kernel patch which used to do that by default is dropped
The kernel patch was dropped as it's different from upstream. Somebody has to set the utf8 mode, and the kernel has decided that it should be userspace policy.
You should probably email the upstream hal list and ask why it's not upstream there.
Richard.
Richard Hughes wrote:
The kernel patch was dropped as it's different from upstream. Somebody has to set the utf8 mode, and the kernel has decided that it should be userspace policy.
You should probably email the upstream hal list and ask why it's not upstream there.
Maybe it's best to leave this to the desktop? KDE already handles this, see: https://bugzilla.redhat.com/show_bug.cgi?id=470592#c7 http://websvn.kde.org/branches/KDE/4.2/kdelibs/solid/solid/backends/hal/hals...
Maybe GNOME should just do the same?
Kevin Kofler
============ note: sorry in advance if I'm a little bit nervous ============ I don't agree, to us [people who need UTF-8] this mean that we should trace fixes in every desktop xfce lxde ...etc.
kde people are the worst in internationalization I remember in kde 2.0 that they promised to fix RTL problem in KDE 3.0 and they started to work at 3.0 but it was garbage support it took **years** to get them fixed till 3.5 and when they are almost perfect in 3.5 they drop all the RTL support and started the make same very stupid assumption from zero on 4.x and we have a big pile of RTL problems most of them are due to the same lessons that they should learn from KDE 3.0
just look to this game how does it behave [if you know the game] http://www.linuxac.org/forum/attachment.php?attachmentid=6226&stc=1&...
most people who helped KDE project to mature through all the years are bored to repeat all that process, they just gave up and moved to gnome.
put yourself in my shoe and you will see things moving backward! why are we moving backward without any reasonable benefit ? why people make the wrong assumptions ? why do we have to discuss trivial things on every project release ?
If you want my opinion it's to squeeze upstream kernel developers till they accept the patch "You stupid! Linux is international this is a fact. This world is multinational love it, or leave it" as sharp and as bold as Linus when he shows his ego
to force people to default to latin-1 is a very stupid assumption it's double stupid to be assumed in this century were I socialize more to people who are in USA, Europe or even South Africa more than I do with my relatives in the city 20KM away
I know that fedorians can do that, yes I'm talking to you Alan! redhat and fedora have sufficient momentum in the kernel development to make that patch accepted.
the only argument I got was this <<EOQ
Forcing utf8 in the kernel was the wrong idea - see bug 454013 for an example of the problems that caused. Further it made Fedora behave differently from all other Linux distributions when mounting vfat volumes, which is bad. EOQ
the Russian person who reported the bug says that he uses
ru_RU.cp1251 or ru_RU.koi8r
but grep '^ru' /usr/share/system-config-language/locale-list ru_RU.UTF-8 utf8 latarcyrheb-sun16 Russian - Русский ru_UA.UTF-8 utf8 latarcyrheb-sun16 Russian (Ukraine)
so it's his customization which lead to the problem not the patch
there used to be problems with iocharset=utf8, but they were solved by passing utf8 withno iocharset=
============================================== excuse me I was angry, I'll try to be calm in the next section of this mail ==============================================
to summarize what have you done by removing this patch 1. you replaced one place of solution into unknown so many possible places of bugs [devicekit, hal, X Y Z desktops, cli commands, unknown number of mount umount desktop applets in less famous WM like window Maker...] 2. you introduced incompatibility with previous fedora releases people who are using previous releases won't be able to see their files correctly [BTW: unlike utf8 which can be validated, latin can't be so it will just produce rubbish if it's invalid] 3. you introduced new incompatibility levels between the same release of fedora [take the possibility of having some file created in one desktop then mounted in another, after logging of or after using live user switch]
as for 1. non of the so many introduced bugs are solved yet since I reported them in F10 betas, I doubt that most can be solved with this mentality
as for 2. you preferred to be compatible with upstream or "other distros" rather than fedora regarding upstream, I'm not convinced that fedorians can't upstream such humble a clean patch and if other distros refers to ubuntu have you checked their launchpad to see how many bugs are filed because they don't have that kernel patch
as for 3. it reminds me with a joke, some one lost a golden ring in some apartment, and since then he is searching for it in all other apartments in the world. Do you think he could find it ?
the ring was lost in the kernel not in hal nor in devicekit and of course not in kde nor gnome patching so many other projects is more stupid than the man in the joke ------- I know that you already made your mind to remove the patch but in this case you should provide a single place that solves the problem
for example make both hal have a fdi policy that sources /etc/sysconfig/filesystem to get the values needed to be passed to the kernel when mounting
and same thing for DeviceKit to at least make sure that at least kde, gnome and xfce will work out of the box consistently [ah and patch kde not to use utf8 but keeping hals default which sources /etc/sysconfig/filesystem]
another joke about two people visiting a relative in the 97th floor on a twin tower, they were using the stairs and just before the 97 floor one of them said I have a bad news and a good news (...) the good news that there is one more floor to go the bad news we are on the wrong tower EOJ
so if you solved the problem in hal or devicekit and still have some issues here or there is just like having one more floor *in the wrong tower*
Muayyad AlSadi wrote:
kde people are the worst in internationalization I remember in kde 2.0 that they promised to fix RTL problem in KDE 3.0 and they started to work at 3.0 but it was garbage support it took **years** to get them fixed till 3.5 and when they are almost perfect in 3.5 they drop all the RTL support
They didn't drop RTL support. In fact they actually improved it, for example KWrite and Kate now support RTL since 4.0.
What did happen is that Plasma uses QGraphicsView which has no or broken RTL support in Qt 4.4. This is fixed in Qt 4.5.
just look to this game how does it behave [if you know the game] [screenshot from KNetWalk]
Well, I don't think the issue is apparent from a screenshot, so please explain what's wrong.
the Russian person who reported the bug says that he uses
ru_RU.cp1251 or ru_RU.koi8r
but grep '^ru' /usr/share/system-config-language/locale-list ru_RU.UTF-8 utf8 latarcyrheb-sun16 Russian - Русский ru_UA.UTF-8 utf8 latarcyrheb-sun16 Russian (Ukraine)
so it's his customization which lead to the problem not the patch
I actually agree with you there. UTF-8 should be the default everywhere, as it is the default charset in Fedora. I think we should even consider just dropping support for non-UTF-8 locales entirely. (In fact, that's exactly what KDE 4 did, Solid just always forces UTF-8 when mounting volumes.)
Kevin Kofler
They didn't drop RTL support. In fact they actually improved it, for example KWrite and Kate now support RTL since 4.0.
don't tell me about that, I live there they did not drop the support but they reinvented the wheel
for example they repeat all the problems in plasma [eg. just look at task bar/kicker] the menu is always on left the favorites menu is always on left and because plasma ias used in every thing it's like dropping rtl support
tables and trees in kde or Qt have RTL problems ...etc. take a look into this http://www.linuxac.org/forum/attachment.php?attachmentid=6236&stc=1&... they are too many http://www.linuxac.org/forum/showthread.php?t=21197
[screenshot from KNetWalk] Well, I don't think the issue is apparent from a screenshot, so please explain what's wrong.
it seems that you don't play that game in that game you need to connect the terminals into the server [earth planet] if you do the terminal monitors turns on look to the monitor in the middle it's not connected to any thing but it on. can you guess why ?
Muayyad AlSadi wrote:
for example they repeat all the problems in plasma [eg. just look at task bar/kicker] the menu is always on left the favorites menu is always on left and because plasma ias used in every thing it's like dropping rtl support
Have you tried Qt 4.5 yet? QGraphicsView got RTL support in 4.5, so Plasma should be better with it. We have Qt 4.5 packages in kde-redhat unstable.
look to the monitor in the middle it's not connected to any thing but it on. can you guess why ?
They mirrored the layout of the pictures and not the pictures themselves. Ugh... I wonder if the Qt 4.5 QGraphicsView fixes that too.
Kevin Kofler
Kevin Kofler wrote:
They mirrored the layout of the pictures and not the pictures themselves. Ugh... I wonder if the Qt 4.5 QGraphicsView fixes that too.
Two better questions are:
- Should this be mirrored /at all/? (I think not, the same way I don't see why you would mirror e.g. mahjongg, chess, tetris, or any of a myriad other games that aren't text-based.)
- Has anyone reported this to the KDE devs? Otherwise how do you expect it to get fixed?
- Has anyone reported this to the KDE devs? Otherwise how do you expect it to get fixed?
I'm a gnome user now, to me that's not a priority because the problem is not with this object or that library the problem is the developers are not educated well regarding internationalization they assume many stupid assumptions and they are happy with that mentality
we have done that before till things are fine in 3.5 do we have to teach them the same silly things over and over it's not rocket engineering, it's just a trivial principle of design all the hard work is already done, the problems are not regarding the complex text rendering engine they are regarding laying out things, Qt knows how to stack things the right way but someone thought that he is too smart to use those routines in the library and he wrote his own hard coded values of Xs and Ys
not only in kde, for example the timeline in pitivi ..etc.
even html have this design problem [instead of start/end they use left/right]
the problem with kde is not the have a piece that is not RTL or BiDi safe, but it's that they choose to jump to the wagon of plasma before making sure it's acceptable to at least some level
so obvious problems that can be discovered by just running kde and looking into the surface.
I just went into that subject to ask is fedora going to do the same thing with utf8 ie. knowing that utf8 is the right thing but choosing to drop that for no good reason
so could we back to the topic, we have less than two months for the release
are we prepared to handle the bugs that we know in advance that we are going to introduce
Muayyad AlSadi wrote:
I'm a gnome user now, to me that's not a priority because the problem is not with this object or that library
The only way these bugs will ever get fixed is if they get reported to https://bugs.kde.org/ . Posting them on some mailing list most KDE developers don't even read is completely unproductive and unhelpful whining.
the problem is the developers are not educated well regarding internationalization they assume many stupid assumptions and they are happy with that mentality
They may not know about all the RTL issues, but that's exactly why you have to report them! Most developers grew up in environments where text is written from left to right, so we aren't always conscious of the issues involved. Only pointing them out can get them fixed.
And I strongly doubt anybody is "happy with that mentality". They just aren't aware that there are any issues because people don't bother reporting them!
we have done that before till things are fine in 3.5 do we have to teach them the same silly things over and over
Yes, because new developers join who are not familiar with the issues yet, and new issues can come up which didn't exist before.
it's not rocket engineering, it's just a trivial principle of design
It's not that trivial when all the text you've ever read is written LTR, which is the case for most European or American developers.
Unfortunately, most of us cannot read Arabic or Hebrew, nor did we grow up reading the writings of Leonardo da Vinci (which are written in mirrored Italian). ;-(
all the hard work is already done, the problems are not regarding the complex text rendering engine they are regarding laying out things, Qt knows how to stack things the right way but someone thought that he is too smart to use those routines in the library and he wrote his own hard coded values of Xs and Ys
Well, the KNetWalk issue is actually the opposite, they're mirroring coordinates where they shouldn't.
Where graphics are involved, there's no magic, it cannot be automatically determined whether they should be mirrored or not. And guess what, in modern UIs (especially things like Plasma, games etc.), there _will_ be graphics involved. So left/right orientation is something which has to be accunted for carefully and explicitly.
I just went into that subject to ask is fedora going to do the same thing with utf8 ie. knowing that utf8 is the right thing but choosing to drop that for no good reason
so could we back to the topic, we have less than two months for the release
are we prepared to handle the bugs that we know in advance that we are going to introduce
Well, in KDE there will be no bug because KDE takes care of mounting devices with the utf8 flag.
(-; sdrager dniK Kevin Kofler
long long debate;
as I said the complex part is already solved, and I think Qt to some level have good RTL support and it has layout management, some people thought that they are too smart and they don't need to use them and they hard coded values
solving that needs long time of documentation to put big signs on every method or property that set x/y coordinate, "avoid using this method unless you are aware of RTL problems, use any of layout management strategies"
and of course it needs to change QA phases ..etc.
because new developers will always come
that's not an excuse, not being able to read Arabic is something sad but it's not the reason for those bugs, those bugs come because some people thought that they are smarter than those who wrote the BiDi layout engine in Qt
for example there are new maintainers come to fedora most of them knows nothing about rpath but fedora won't accept an rpm with rpath why ? because in the review process there is a QA about rpath there is a good documentation about rpaths that's why having new maintainers is not an excuse
and as I said KDE was just an failure story, it's not the problem I'm trying to solve by this post the problem wasn't with the new code having RTL problems it's how they got to those problem AGAIN
let's back to the topic
Well, in KDE there will be no bug because KDE takes care of mounting devices
with the utf8 flag.
have you read the consistency problem
3. you introduced new incompatibility levels between the same release of fedora [take the possibility of having some file created in one desktop then mounted in another, after logging of or after using live user switch]