Messages in this thread | | | From | Frank Pan <> | Date | Thu, 27 May 2010 20:53:37 +0800 | Subject | Re: [PATCH 0/2] Enlarge the storage of chars in virtual terminal |
| |
Greetings,
> I'm not an export on the issue but if I'm not mistaken it gets more > complex than that. It took quite some time to solve the problem > properly even on full desktop envs. Maybe the issue on full desktop envs comes from different frameworks? (gtk, qt, etc...) On tty, it's just a char device. It may have difficulties, but unknown before totally implement it. AFAIK, it's easier than desktop envs.
> And other than yourself, how many would such users be? What's your > reason for not using X other than "console looks cooler"? Even if you > have some valid reason to not use X and absolutely have to have > multilingual support, what prevents you from using fb based terminals > like jfbterm which already works with input and all without > introducing any i18n related complexities into kernel? To me, it > seems like low activiy on jfbterm seems to show the low demand for > such feature. So, just use X. Not everyone likes X. Forcing one who think X is a huge thing using X even when checking emails is... too bad. People may have their own choice, I think.
A brief view of jfbterm tells me it's a good thing, and the source code tells me that it does almost the same thing in vt: esc char handling, terminal configuration, etc. Plus, pcf parsing and encoding identification. That's why I think we are re-inventing the wheel. Kernel do esc char handling, kernel do terminal configuration, kernel do utf-8 decoding, kernel do dynamic font changing. Why don't we just enlarge the glyphs a font can have, so all the things go well?
Thanks for reply.
-- Frank Pan
Computer Science and Technology Tsinghua University -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |