kamion2-devel Mailing List for Kamion (Page 3)
Status: Beta
Brought to you by:
ivan-cukic
Menu
▾
▴
kamion2-devel — Kamion Development List
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(39) |
Oct
(10) |
Nov
(11) |
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(5) |
Feb
(12) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ivan <iva...@gm...> - 2007-09-28 14:59:15
|
=46irst of all, just to say that I'm talking relying on what I have read at=
=20
techbase, because I had no closer (personal) experience with i18n in KDE.
Original code:
> i18n("<b>All Applications</b>:<br>Show all available applications"));
Problem is markup in i18n text - nonsemantic markup
Your code:
> "<b>"+i18n("All Applications:")+"</b><br>"+i18n("Show all available=20
applications"));
Problem is the separation of those two strings. Those strings are not=20
independent from one another (semantically). The second should be detailed=
=20
description of the first, so they should be connected.
Personally, I like the way they used on that techbase page I noted in one o=
f=20
the previous mails because it fixes my glitches, and doesn't introduce new=
=20
ones.
|
|
From: Ivan <iva...@gm...> - 2007-09-28 14:35:56
|
> I agree, but I don't think that linking against QT4 can be accepted by
> gtk+ people. We need a true QT free library if we want to be nice and
Ok, I agree with that.
> But I found strings inside the .ui, not in the code and what was
> inside the .ui was a large blob of css declarations mixed with text.
Yes. I thought of moving all of that into the code... I'll see what you've=
=20
done.
> Very difficult to handle and unnecessary complicated, take a look in
> .pot or in original ui in XML mode.
> If you take a look to my sources (you have it) you will find that we
> can have same functionality in a simpler way.
> Anyway, I am open to any advice.
I was out today, so had no chance to check the code... will do in a matter =
of=20
hours though.
> PS: I modified main window .ui by hand, but I was able to load it in
> qt4 designer.
Well, I do that all the time, so no sweat :)
=46urther comments soon... :)
=2D-=20
There is a better way of life and it's not so hard to find
If you live and let the people in your world speak its mind
-- Deep Purple
|
|
From: Luca B. <lbe...@gm...> - 2007-09-28 08:44:17
|
> Yes, it had to be everywhere where Qt was needed, so it is in > Kamion_SAXDriver_QT.cpp > Kamion_SAXDriver_QT.h > Kamion_System.cpp no problem here, we can isolate them > I'm not happy with binding with kdelibs. That would be "a bit" too much - it > would mostly invalidate the reasons for separation of the library and UIs. Qt > may be a dependency that people (Gtk-guys) would be willing to obey, but > dragging in the whole kdelibs only because of localization is too much. I agree, but I don't think that linking against QT4 can be accepted by gtk+ people. We need a true QT free library if we want to be nice and polite with our brothers. But we can do this later in the developing phase. Is for that I want to use gettext for the library. You translate one time only. But It is better to have a separate project for that. > we decide to go for fullblown-QT-revamp, it would be strange to use an > external library for a thing that QT has) Yes and no. We live in a mixed world (KDE,QT,...). I would like to change a piece at time. > There was an article at techbase about that - formating it semantically > instead of html (http://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics) You are right as always :) But I found strings inside the .ui, not in the code and what was inside the .ui was a large blob of css declarations mixed with text. Very difficult to handle and unnecessary complicated, take a look in .pot or in original ui in XML mode. If you take a look to my sources (you have it) you will find that we can have same functionality in a simpler way. Anyway, I am open to any advice. PS: I modified main window .ui by hand, but I was able to load it in qt4 designer. bye lb |
|
From: Ivan <iva...@gm...> - 2007-09-28 08:06:54
|
> i don't think (yet). i'm having troubles building qt4 in my bsd box. but
> i'm loving the pace you two are setting! let's go! :)
Well, now we're just discussing, so you don't need the QT installed :)
=2D-=20
There is a better way of life and it's not so hard to find
If you live and let the people in your world speak its mind
-- Deep Purple
|
|
From: Ivan <iva...@gm...> - 2007-09-28 08:05:12
|
> Ok, let's pollute this mailing list with one more message Keep on polluting :) > In libkamion QString are used in many places, so it is difficult to > really isolate the library from QT4. Yes, it had to be everywhere where Qt was needed, so it is in Kamion_SAXDriver_QT.cpp Kamion_SAXDriver_QT.h Kamion_System.cpp libkamion.cpp Everything else is Qt-Free > I hope do do new development, instead of refactoring, if the base > architecture is good enough and this is so, *but* now we have two > types of dependecncies in two project parts: KDE and QT with different > standards, different resource installation places and so on. I don't > like using two toolchains for same project. Maybe we have to bind with > KDE in the library too (or maybe not). I'm not happy with binding with kdelibs. That would be "a bit" too much - i= t=20 would mostly invalidate the reasons for separation of the library and UIs. = Qt=20 may be a dependency that people (Gtk-guys) would be willing to obey, but=20 dragging in the whole kdelibs only because of localization is too much. > In my local copy of Kamion I am using gexttext for the library and > KLocale for the GUI. The GUI is working, but the library no. I try to > avoid using QT routines because I don't want any interference with KDE > ones. You could ask on kde-devel list if there would be any interference at all. = (if=20 we decide to go for fullblown-QT-revamp, it would be strange to use an=20 external library for a thing that QT has) > In the UI there are HTML labels that can't be translated easily, so I > divided complex text labels in pieces of text having same style. There was an article at techbase about that - formating it semantically=20 instead of html=20 (http://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics) =2D-=20 Those people who think they know everything are a great annoyance to those = of=20 us who do. -- Isaac Asimov |
|
From: Pedro de C. <lei...@gm...> - 2007-09-27 23:38:23
|
> go for libkamion. Let me know what all you think. i don't think (yet). i'm having troubles building qt4 in my bsd box. but i'm loving the pace you two are setting! let's go! :) Pedro. Em Sexta 28 Setembro 2007, Luca Bellonda escreveu: > Ok, let's pollute this mailing list with one more message > > In libkamion QString are used in many places, so it is difficult to > really isolate the library from QT4. > > > > This means that we have to introduce objects in the library to hide > > > QT4 dependencies for catalog loading and string translation. > > The alternative would be to make the QT (QtCore and QtXml, not QtGui) a real > > dependency. It would require a overhaul to the lib (to remove current > > middle-layers), but if you all are interrested in some more complicated > > development, I am too. > > I hope do do new development, instead of refactoring, if the base > architecture is good enough and this is so, *but* now we have two > types of dependecncies in two project parts: KDE and QT with different > standards, different resource installation places and so on. I don't > like using two toolchains for same project. Maybe we have to bind with > KDE in the library too (or maybe not). > In my local copy of Kamion I am using gexttext for the library and > KLocale for the GUI. The GUI is working, but the library no. I try to > avoid using QT routines because I don't want any interference with KDE > ones. > > In the UI there are HTML labels that can't be translated easily, so I > divided complex text labels in pieces of text having same style. > > > > > 3) I inserted scripts from KDE i10n project, but these scrips are > > > intended to be run in batch and not in the make phase. I have to > > > discover how to insert it into the build cycle with cmake. Does > > > someone has some advices about this? > > I'm not sure you should add it to cmake at all. The usual approach is to call > > the scripts once in a while... for example before committing to SVN or > > something. The strings do not change that often once you give them to > > translation teams. > ok, I will learn more. > > I soon will post my modified copy. I am still in doubt for the way to > go for libkamion. Let me know what all you think. > > bye > > Luca Bellonda > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Kamion2-devel mailing list > Kam...@li... > https://lists.sourceforge.net/lists/listinfo/kamion2-devel > |
|
From: Luca B. <lbe...@gm...> - 2007-09-27 23:32:24
|
Ok, let's pollute this mailing list with one more message In libkamion QString are used in many places, so it is difficult to really isolate the library from QT4. > > This means that we have to introduce objects in the library to hide > > QT4 dependencies for catalog loading and string translation. > The alternative would be to make the QT (QtCore and QtXml, not QtGui) a real > dependency. It would require a overhaul to the lib (to remove current > middle-layers), but if you all are interrested in some more complicated > development, I am too. I hope do do new development, instead of refactoring, if the base architecture is good enough and this is so, *but* now we have two types of dependecncies in two project parts: KDE and QT with different standards, different resource installation places and so on. I don't like using two toolchains for same project. Maybe we have to bind with KDE in the library too (or maybe not). In my local copy of Kamion I am using gexttext for the library and KLocale for the GUI. The GUI is working, but the library no. I try to avoid using QT routines because I don't want any interference with KDE ones. In the UI there are HTML labels that can't be translated easily, so I divided complex text labels in pieces of text having same style. > > 3) I inserted scripts from KDE i10n project, but these scrips are > > intended to be run in batch and not in the make phase. I have to > > discover how to insert it into the build cycle with cmake. Does > > someone has some advices about this? > I'm not sure you should add it to cmake at all. The usual approach is to call > the scripts once in a while... for example before committing to SVN or > something. The strings do not change that often once you give them to > translation teams. ok, I will learn more. I soon will post my modified copy. I am still in doubt for the way to go for libkamion. Let me know what all you think. bye Luca Bellonda |
|
From: Ivan <iva...@gm...> - 2007-09-27 14:52:57
|
> 2) In the library there are strings that need to be kept there. We
> can't move showYesNoQuestion arguments into user interface for two
I had a vision of java's exception system regarding this... but it could be=
an=20
overkill (again)
> This means that we have to introduce objects in the library to hide
> QT4 dependencies for catalog loading and string translation.
The alternative would be to make the QT (QtCore and QtXml, not QtGui) a rea=
l=20
dependency. It would require a overhaul to the lib (to remove current=20
middle-layers), but if you all are interrested in some more complicated=20
development, I am too.
IF this is the way to go, we should make an inquiry amongst KDE developers=
=20
what features they would like to have concerning the resources definitions.
> 3) I inserted scripts from KDE i10n project, but these scrips are
> intended to be run in batch and not in the make phase. I have to
> discover how to insert it into the build cycle with cmake. Does
> someone has some advices about this?
I'm not sure you should add it to cmake at all. The usual approach is to ca=
ll=20
the scripts once in a while... for example before committing to SVN or=20
something. The strings do not change that often once you give them to=20
translation teams.
Cheers
=2D-=20
Sanity is the trademark of a weak mind.
-- Mark Harrold
|
|
From: Luca B. <lbe...@gm...> - 2007-09-26 19:27:31
|
Hi to all, I am trying to insert i18n in the current version and I have some questions to pose 1) Do you think that gnome project can build a user interface for libkamion? In this case we really need two separate pot files (gui and lib) 2) In the library there are strings that need to be kept there. We can't move showYesNoQuestion arguments into user interface for two reasons: for each message we need to insert a new parameter to address the new message, vanishing in fact the separation of the engine from the GUI. More, we can't easily change the user interface if we have to update it for each new message. This means that we have to introduce objects in the library to hide QT4 dependencies for catalog loading and string translation. 3) I inserted scripts from KDE i10n project, but these scrips are intended to be run in batch and not in the make phase. I have to discover how to insert it into the build cycle with cmake. Does someone has some advices about this? 4) l10n means that a little code refactoring is needed in messages composition. I think to translate even command line messages, but not the debug ones. bye lb |
|
From: Andy C. <and...@gm...> - 2007-09-26 08:08:17
|
TW9ybmluZyBBbGwKCkkgaGF2ZSBqdXN0IHNldCB1cCBteSBTRiBhY2NvdW50Li4uLi4KCnRoZV9n cmVhdF9nb256bwoKQ2hlZXJzCgpBbmR5CgpPbiAyNS8wOS8yMDA3LCBQZWRybyBkZSBDYXJ2YWxo byA8bGVpdGUuY2FydmFsaG9AZ21haWwuY29tPiB3cm90ZToKPgo+IEVtIFRlcudhIDI1IFNldGVt YnJvIDIwMDcsIEl2YW4gyHVraeYgZXNjcmV2ZXU6Cj4gPiBTbyBBVE0sIHRoZSB0aGluZ3MgYXJl IGRpdmlkZWQgaW50byB0aGVzZSBwYXJ0czoKPiA+Cj4gPiAqIGxpYnJhcnkgICAgICAgICAtIFBl ZHJvCj4gPiAqIGNvbnNvbGUgICAgICAgICAtIEFuZHkKPiA+ICogR1VJICAgICAgICAgICAgIC0g VG9rZSAgICAgKGFscnVhKQo+ID4gKiByZWNpcGUgZGF0YWJhc2UgLSBManVib21pciAob3BlbnNo aW55KQo+ID4gKiBpMThuICAgICAgICAgICAgLSBMdWNhICAgICAobGJlbGwpCj4gPgo+ID4gSSds bCB0cmFuc2ZlciB0aGUgY29kZSB0byBTRiBTVk4sIGFuZCB3aWxsIGluIHRoZSBmdXR1cmUgYWN0 IGFzIGEgcHJveHkKPiB0bwo+ID4gS0RFJ3MgU1ZOLgo+ID4KPiA+IFBlZHJvIGFuZCBBbmR5LCB3 aGF0IGFyZSB5b3VyIG91ciBhY2NvdW50cyBvbiBTRj8KPiA+Cj4KPiBzb3JyeSwgaSBoYWQgc29t ZSB0cm91YmxlcyB3aXRoIG15IHBjLiB0d28gd29yZHM6IGxpYm5leHBhdCBnZW50b28KPgo+IGkn dmUgcmVjZW50bHkgcmVnaXN0ZXJlZCBpbiBzZiB3aXRoICJwZWRyb2doYW5kaSIuCj4KPiB0aHgu Cj4KPgo+Cj4KPiA+IHAucy4gQWxsIG9mIHlvdSB3aG8gYXJlIGFkZGVkIHRvIHRoZSBwcm9qZWN0 IG9uIFNGIGhhdmUgdGhlIGFjY2VzcyBmb3IKPiB3ZWJzaXRlCj4gPiBjaGFuZ2luZywgU1ZOLCBh bmQgZXZlcnl0aGluZyBlbHNlLi4uIHlvdSdsbCBnZXQgYWRtaW5pc3RyYXRpdmUKPiBwcml2aWxl Z2VzIGFzCj4gPiB3ZWxsIHdoZW4gdGhpbmdzIHN0YXJ0IHJvbGxpbmcuLi4KPiA+Cj4gPgo+Cj4K Pgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBUaGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6 IE1pY3Jvc29mdAo+IERlZnkgYWxsIGNoYWxsZW5nZXMuIE1pY3Jvc29mdChSKSBWaXN1YWwgU3R1 ZGlvIDIwMDUuCj4gaHR0cDovL2Nsay5hdGRtdC5jb20vTVJUL2dvL3ZzZTAxMjAwMDAwNzBtcnQv ZGlyZWN0LzAxLwo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCj4gS2FtaW9uMi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBLYW1pb24yLWRldmVsQGxpc3RzLnNv dXJjZWZvcmdlLm5ldAo+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3Rp bmZvL2thbWlvbjItZGV2ZWwKPgo= |
|
From: Pedro de C. <lei...@gm...> - 2007-09-25 13:21:41
|
Em Ter=C3=A7a 25 Setembro 2007, Ivan =C4=8Cuki=C4=87 escreveu: > So ATM, the things are divided into these parts: >=20 > =C2=A0* library - Pedro > =C2=A0* console - Andy > =C2=A0* GUI - Toke (alrua) > =C2=A0* recipe database - Ljubomir (openshiny) > =C2=A0* i18n - Luca (lbell) >=20 > I'll transfer the code to SF SVN, and will in the future act as a proxy t= o=20 > KDE's SVN. >=20 > Pedro and Andy, what are your our accounts on SF? >=20 sorry, i had some troubles with my pc. two words: libnexpat gentoo i've recently registered in sf with "pedroghandi". thx. > p.s. All of you who are added to the project on SF have the access for we= bsite=20 > changing, SVN, and everything else... you'll get administrative privilege= s as=20 > well when things start rolling... >=20 >=20 |
|
From: Ivan <iva...@gm...> - 2007-09-25 08:20:07
|
So ATM, the things are divided into these parts: =A0* library - Pedro =A0* console - Andy =A0* GUI - Toke (alrua) =A0* recipe database - Ljubomir (openshiny) =A0* i18n - Luca (lbell) I'll transfer the code to SF SVN, and will in the future act as a proxy to= =20 KDE's SVN. Pedro and Andy, what are your our accounts on SF? p.s. All of you who are added to the project on SF have the access for webs= ite=20 changing, SVN, and everything else... you'll get administrative privileges = as=20 well when things start rolling... =2D-=20 Those people who think they know everything are a great annoyance to those = of=20 us who do. -- Isaac Asimov |
|
From: Andy C. <and...@gm...> - 2007-09-25 08:08:07
|
Morning Apologies for the silence on my part. I have been away for the weekend and have only just caught up with the mails. This would be my first KDE (or OOS) project so forgive me if I am a little naive. I would be really interested in coding the Command line tools and helping with the GUI and Library code. I would be also happy to work with someone to update the website as I think we could do with providing a bit more info in order to attract different projects/developers to cooperate with the project. Perhaps,as already suggested, we could come up with a work plan so we all have a map of things that need to get done? I think it would be really use full if Nathan can forward on that article. Cheers Andy |
|
From: Ivan <iva...@gm...> - 2007-09-25 08:02:37
|
> I am not used to subversion, maybe to use sf site first is not a bad > idea... Anyway, I will have to learn. Where are latest sources now? Well, for both sf and kde, you'll need to see the basics of SVN. The latest= =20 sources are in KDE's SVN (trunk/playground/utils/kamion/) > The mailing lists web viewer at sourceforge is not handling UTF-8 > correctly I suppose. I see my previous mail as a binary blob. Bummer... that's out of my reach :( =2D-=20 You know, there are many people in the country today who, through no fault of their own, are sane. Some of them were born sane. Some of them became sane later in their lives... -- Monty Python's Flying Circus |
|
From: Luca B. <lbe...@gm...> - 2007-09-24 19:17:59
|
2007/9/23, Toke H=F8iland-J=F8rgensen <to...@to...>: > I'm good with either... > > -Toke I am not used to subversion, maybe to use sf site first is not a bad idea..= . Anyway, I will have to learn. Where are latest sources now? The mailing lists web viewer at sourceforge is not handling UTF-8 correctly I suppose. I see my previous mail as a binary blob. Luca Bellonda |
|
From: Ivan <iva...@gm...> - 2007-09-23 17:41:42
|
I have synced the code with the latest kdelibs so it compiles (so much for = the=20 frozen APIs since aKademy) and formated the code KDE4 style. |
|
From: Toke <to...@to...> - 2007-09-23 16:56:07
|
> Would you like to switch the Kamion development to SourceForge's SVN so > that you do not need to get KDE SVN account right away? I'm good with either... -Toke |
|
From: Ivan <iva...@gm...> - 2007-09-23 16:28:23
|
Hi all, Would you like to switch the Kamion development to SourceForge's SVN so tha= t=20 you do not need to get KDE SVN account right away? Cheers |
|
From: Ivan <iva...@gm...> - 2007-09-23 16:24:59
|
> If the goal is to separate the presentation entirely from the > implementation, I suppose it should be a goal to remove any QT dependenci= es > from the library, right? As I've already said in one of the last mails: ivan> So for every external library (ATM - QT4 and SqlLite3), there's an ivan> abstract mid-layer that can be implemented using some other library. ivan> This approach would make it easier to implement essentially the same ivan> library that would use libxml (or xerces-c) and PThreads. So we *could* remove any QT dependencies while remaining both source and [I= =20 think also] binary compatible. This way we could have two implementations i= n=20 the same source tree - so if a distribution doesn't ship QT, it could=20 ship 'the other' libkamion binary. > little uncertain as to what I need. Are there any primer docs on KDE > development out there (introduction to cmake, what parts I need to checko= ut > from SVN, etc)? http://techbase.kde.org/ is always a good start. For Kamion you'll need onl= y=20 kdelibs. > Also, is the GUI currently 'pure' QT4, or are there KDE specific stuff > there as well (I'm guessing the latter)? Yes, there are some things used like KIcon in Kamion (GUI only). The librar= y=20 has no kde deps whatsoever. Cheers =2D-=20 A positive attitude may not solve all your problems, but it will annoy enou= gh=20 people to make it worth the effort -- Herm Albright |
|
From: Toke <to...@to...> - 2007-09-23 10:19:20
|
Hi everyone, > Reasons for the lib - UI separation are: > - Separated presentation from implementation > - Possibility to have more than one UI (KDE4 GUI, console-tools...) > without having to duplicate code. There's allways a possibility to > statically include the library into the project, but I do not see the > reason for it. - Possibility for 3rd-party applications that want to have > backup/transfer functionality built-in to use libkamion and Kamion archive > format If the goal is to separate the presentation entirely from the implementatio= n,=20 I suppose it should be a goal to remove any QT dependencies from the librar= y,=20 right? > Ok, I'll see to add you to the project. Ant the rest of you, do you have > the sf accounts? And KDE SVN accounts? My sf.net account name i 'alrua' - I don't have a KDE SVN account. Also, as= I=20 mentioned earlier, I've never done any KDE development before, so I'm a=20 little uncertain as to what I need. Are there any primer docs on KDE=20 development out there (introduction to cmake, what parts I need to checkout= =20 from SVN, etc)? Also, is the GUI currently 'pure' QT4, or are there KDE specific stuff ther= e=20 as well (I'm guessing the latter)? Cheers, =2DToke |
|
From: Ivan <iva...@gm...> - 2007-09-23 07:47:18
|
On Saturday 22 September 2007 23:21:03 Luca Bellonda wrote: > Hi to all, I am evaluating changes to kamion project to support i18n. > First, the subdivision in GUI and library is real? If it is so, we > need two set of translation files, elsewhere one is sufficient. We need only one set. The library doesn't really need any hardcoded strings= =20 into it. ATM, there are only two user-displayed hardcoded strings in the li= b=20 (progress reporting) - they should be removed, and replaced by=20 library-class-messages that UI would turn generate it's strings from. Reasons for the lib - UI separation are: - Separated presentation from implementation - Possibility to have more than one UI (KDE4 GUI, console-tools...) without having to duplicate code. There's allways a possibility to statically include the library into the project, but I do not see the reason for it. - Possibility for 3rd-party applications that want to have backup/transfer functionality built-in to use libkamion and Kamion archive format > Do we need a new class in the library to load the library catalog at > the library start to be independent from KDE4 as we can? I'm not sure what you're aiming at, but if you're referring to=20 DatabaseReader/Writer/Driver classes, they are needed to support different= =20 database backends. Since the recipes are XML files, they are slow to parse = on=20 each program start, so they are 'compiled' into a sqlite3 database. Those a= re=20 the two existing backends - the recipe XML /is/ a valid kamion database. Th= e=20 XML database format is used in the Kamion archive as Manifest (the file tha= t=20 contains the data about apps and resources that are packet within) > Incidentally I am sourceforge user lbell. Ok, I'll see to add you to the project. Ant the rest of you, do you have th= e=20 sf accounts? And KDE SVN accounts? > @Ivan > >Sorry for late response, I had a wedding to attend to :( > sre=E6no :) Well, fortunately, it wasn't my wedding... :) Cheers =2D-=20 A positive attitude may not solve all your problems, but it will annoy enou= gh=20 people to make it worth the effort -- Herm Albright |
|
From: Luca B. <lbe...@gm...> - 2007-09-22 21:56:33
|
Hi to all, I am evaluating changes to kamion project to support i18n. First, the subdivision in GUI and library is real? If it is so, we need two set of translation files, elsewhere one is sufficient. In the first case we need to structure libkamion subdirectory with two children: src and po. In kcamion-gui it is sufficient to add po subdir only. Do we need a new class in the library to load the library catalog at the library start to be independent from KDE4 as we can? If kamion will be a KDE application, the translation files will be added to KDE files, with unique file names, else I have to check where the files will be installed and if the standard KLocale routines are able to find it. Another question is if cmake is able to generate a po target. In the KDE project, the message extracting is run on the server periodically, but we should able to extract string on program generation. Next week I will check cmake options, for now I need to know if we should handle one or two separate projects. Incidentally I am sourceforge user lbell. Bye Luca Bellonda |
|
From: Luca B. <lbe...@gm...> - 2007-09-22 21:21:02
|
SGkgdG8gYWxsLCBJIGFtIGV2YWx1YXRpbmcgY2hhbmdlcyB0byBrYW1pb24gcHJvamVjdCB0byBz dXBwb3J0IGkxOG4uCkZpcnN0LCB0aGUgc3ViZGl2aXNpb24gaW4gR1VJIGFuZCBsaWJyYXJ5IGlz IHJlYWw/IElmIGl0IGlzIHNvLCB3ZQpuZWVkIHR3byBzZXQgb2YgdHJhbnNsYXRpb24gZmlsZXMs IGVsc2V3aGVyZSBvbmUgaXMgc3VmZmljaWVudC4KSW4gdGhlIGZpcnN0IGNhc2Ugd2UgbmVlZCB0 byBzdHJ1Y3R1cmUgbGlia2FtaW9uIHN1YmRpcmVjdG9yeSB3aXRoIHR3bwpjaGlsZHJlbjogc3Jj IGFuZCBwby4gSW4ga2NhbWlvbi1ndWkgaXQgaXMgc3VmZmljaWVudCB0byBhZGQgcG8gc3ViZGly Cm9ubHkuCkRvIHdlIG5lZWQgYSBuZXcgY2xhc3MgaW4gdGhlIGxpYnJhcnkgdG8gbG9hZCB0aGUg bGlicmFyeSBjYXRhbG9nIGF0CnRoZSBsaWJyYXJ5IHN0YXJ0IHRvIGJlIGluZGVwZW5kZW50IGZy b20gS0RFNCBhcyB3ZSBjYW4/CklmIGthbWlvbiB3aWxsIGJlIGEgS0RFIGFwcGxpY2F0aW9uLCB0 aGUgdHJhbnNsYXRpb24gZmlsZXMgd2lsbCBiZQphZGRlZCB0byBLREUgZmlsZXMsIHdpdGggdW5p cXVlIGZpbGUgbmFtZXMsIGVsc2UgSSBoYXZlIHRvIGNoZWNrIHdoZXJlCnRoZSBmaWxlcyB3aWxs IGJlIGluc3RhbGxlZCBhbmQgaWYgdGhlIHN0YW5kYXJkIEtMb2NhbGUgcm91dGluZXMgYXJlCmFi bGUgdG8gZmluZCBpdC4KQW5vdGhlciBxdWVzdGlvbiBpcyBpZiBjbWFrZSBpcyBhYmxlIHRvIGdl bmVyYXRlIGEgcG8gdGFyZ2V0LiBJbiB0aGUKS0RFIHByb2plY3QsIHRoZSBtZXNzYWdlIGV4dHJh Y3RpbmcgaXMgcnVuIG9uIHRoZSBzZXJ2ZXIgcGVyaW9kaWNhbGx5LApidXQgd2Ugc2hvdWxkIGFi bGUgdG8gZXh0cmFjdCBzdHJpbmcgb24gcHJvZ3JhbSBnZW5lcmF0aW9uLgpOZXh0IHdlZWsgSSB3 aWxsIGNoZWNrIGNtYWtlIG9wdGlvbnMsIGZvciBub3cgSSBuZWVkIHRvIGtub3cgaWYgd2UKc2hv dWxkIGhhbmRsZSBvbmUgb3IgdHdvIHNlcGFyYXRlIHByb2plY3RzLgoKSW5jaWRlbnRhbGx5IEkg YW0gc291cmNlZm9yZ2UgdXNlciBsYmVsbC4KCkBJdmFuCj5Tb3JyeSBmb3IgbGF0ZSByZXNwb25z ZSwgSSBoYWQgYSB3ZWRkaW5nIHRvIGF0dGVuZCB0byA6KApzcmXmbm8gOikKCgpCeWUKCkx1Y2Eg QmVsbG9uZGEK |
|
From: Ivan <iva...@gm...> - 2007-09-22 18:02:07
|
Sorry for late response, I had a wedding to attend to :( @Nathan Yes, I think the article could be a nice way to introduce the user side of Kamion. @Ljubomir I have attached a XSD of the recipe format, and a sample file for Kopete. In a nutshell, every application has it's "user-state data" - the data that is usually located in $HOME/.something/... That data can be semantically divided into so called "resources" - for KMail, it could (for example) be: configuration files, account settings and messages. For each of the resources, the developer can assign which files belong to it (shell patterns can be used too - because of kopete - this is done with a dirty hack by using bash to invoke tar achiever which I would like to be changed in the future). The purpose of dividing to resources is to enable the user to backup for example e-mail messages, and not settings. Well, that is all from the 3rd-party application developer perspective. As for plans, it's a bit early to be precise (especially since I'm leaving the maintainership position so I'm not in charge anymore), but some thoughts of mine (as far as the features are concerned) are: * (far future) add unification for different applications to export same data - for example to provide some standard for email programs - how to format it's resources so that you could pack the data from kmail and import into thunderbird on another installation. * Scripting - optional pre-packing and post-extracting shell scripts - so that they could filter unnecessary data or something. * Changeable file locations for resources - the developers would be able to tell Kamion to search for the file location inside another file (for example inside a config file) * Dynamic resources - so that different accounts in mail programs appear under different resources, and not in one common - mail messages. It would be great if the devs tell us what would they need so that we don't have to make dirty patches (like the one I've mentioned earlier) to already finished and working code. Cheers! -- Those people who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov |
|
From: Nathan S. <san...@gm...> - 2007-09-21 21:16:28
|
Hi, As Ivan mentioned, I am a freelance journalist and have covered Kamion a few times in the past. An article I wrote for Linux Format magazine issue 93 (May 2007) might be useful as a quick way to get you all up to speed on the Kamion Qt4 interface and the basics of libKamion - if it's not too outdated by now. Ivan, if you think it would be useful, I can look into the possibility of distributing a PDF of the article to everyone on the mailing list. The only holdup would be copyright issues with the publisher. I should also note that I made an informal survey of application developers while writing that article. The developers were told a bit about Kamion and directed to its website for more information (not that the website is in a particularly informative state), asked whether or not they had ever heard of Kamion, asked if they plan to or would like to provide recipes (of course, we weren't calling them that at the time, but I think it's a terrific name), and asked what would be necessary to encourage them to provide recipes. If I remember correctly, I got responses from Abiword, Gaim, Kaffeine, Kate, K3b, and MPlayer developers. The vast majority of them had not heard of Kamion before and were not willing to comment on potential support until they got more information on the project. I would be willing to collect these responses and share them, but I'm not sure if there are any privacy concerns attached to them. If anyone would like to see them, let me know. I think their responses indicate that the first thing to do regarding Kamion promotion is to make a formal developer resource page to educate application developers so that they will seriously consider providing recipes. I hope some of that was useful and that I can be of some help with the Kamion revival, though I am not qualified to do any programming on the project. Regards, ~Nathan Sanders On 9/21/07, Ljubomir Simin <lju...@gm...> wrote: > Hi, > > In order to start talking with app developers, I need to know how the > kamion works from the perspectives of kamion user, and app developer. > > It could be also be handy, if we agree on some work plan, so that I > know what features I can advertise :) > > -- > Ljubomir Simin > Registered Linux User #351181 > http://counter.li.org > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Kamion2-devel mailing list > Kam...@li... > https://lists.sourceforge.net/lists/listinfo/kamion2-devel > |