kamion2-devel Mailing List for Kamion (Page 2)
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: Luca B. <lbe...@gm...> - 2007-11-05 21:35:29
|
This discussion leads us very far. Is Kamion a tool to migrate application state or user data too? If first case is difficult to treat, the second one is even more. Let's do a simple example: let's suppose to save text document related data. User will produce documents using different programs. If we export KOffice data, should we export Document directory too? And what if we export Open Office profile? Should we do same backup of same data? When we restore Open Office, should we overwrite same data files restored with KOffice profile? And what if in the target system some data files with the same name exist or have more recent date? Let's suppose instead, to stay in the simple case, that we save application state only. After the restore operation, the paths in the data or configuration files that point to positions in the old system should be remapped? And how? (we can save paths with backups) If the user choose a non standard directory to restore data, should KDE application configuration files change to reflect new path? >b) i still don't get the point of asking the authors to script something for >us. what could they script? (that we can't in advance) They can build, via script, the application specific data directory path. They can, using application configuration file, build paths. We can't know about that when dealing with a lot of different applications. Anyway, should we take into account the scenery of total user migration of a user account from a distribution/version to another one? The user then will expect to export *all* her data correctly, after all Kamion is a user tool. As general idea, maybe we can propose Kamion as backup tool called directly from inside KDE applications. For that do we need more control against concurrent execution? Are these questions important for you? Maybe we can start a collaborative document on Google to define what precisely Kamion purposes are, present use cases, and gain a manual in the meantime. bye lb |
|
From: Ivan <iva...@gm...> - 2007-11-02 09:20:52
|
* First of all, I don't see the point of archiving music collections using= =20 Kamion (people know where they keep the music), but OK, it raises a couple = of=20 general issues. * I mostly agree with Toke, except for one little thing > Toke > This script could then pop up a dialog asking the user which=20 > Toke > part(s) of their music library they want to export. The pop up dialogue would mean breaking the Kamion's user interface... if i= t's=20 necessary to have it, than I would propose a "detailed selection" button (f= or=20 the items that need it) or something like that... (just popping is not an=20 expected behaviour when you select something...) * About scripting. As we know, most of the application's resource=20 locations /are/ accessible through the application's config files. > Pedro > what could they script? (that we can't in advance) I agree with this, but not with the point it makes. Why? The point that I s= ee=20 is that we could (and should) write those scripts for them, not that we=20 shouldn't have scripting. (When I say scripting, I refer to shell scripts,= =20 and their output, not the scripting inside the Kamion itself) The main reason is that scripting is the fastest way to add features. - no= =20 need for recompiling, watching out to retain binary compatibility etc. =46or example, we need (for some applications) a way to get a value from th= eir=20 config file - write a script whose parameters are config file, section and= =20 variable name. And recipe can call it using something like this <script name=3D"configValue" params=3D"amarokrc,category,variable" /> > Daniel > so the applications could update (through a standar library, if > Daniel > possible) where they keep their files (in=20 Nice idea, but has a couple of weak points. The first is the fact that Amar= ok=20 already writes the locations somewhere, so it would produce redundancy. And= =20 the second (actually, more important) is that it would require changes in t= he=20 Amarok's code itself, and that it would have a new library dependency, whic= h=20 I don't think the developers (not only Amarok's) would want. > Daniel > b) include some kind of scripting language to make decisions, > Daniel > check for file existence, etc No objections to this. > Daniel > c) make the backup able to work with simbolic links, and let the > Daniel > application link on a folder anything that wants backed up. Again a very clean approach. But then we would loose the ability to backup= =20 symbolic links. The thing I hate about the tar command is that you can't force it to do a b= it=20 more advanced stuff. For example, i wanted to use FIFO streams instead of=20 creating real files in /tmp thus removing the 'low disk space' errors. But= =20 tar doesn't pack the contents of FIFO, it packs info about that FIFO... (or= =20 at least I didn't find the right switch...) I'm glad that this discussion has started... Cheers all! =2D- Money can't buy happiness, but neither can poverty. -- Leo Rosten |
|
From: Pedro de C. <lei...@gm...> - 2007-11-02 06:36:44
|
Hei!
while this is a particular app, we should generalise to fit other=20
applications.
So, amarok has a collection. Reading its config (
~/.kde/share/config/amarokrc) they have the section of [Collection Folders]=
=20
with different folders.=20
regarding a) i agree with Toke. our lib just needs a list of dirs named by=
=20
the recipe to backup. That list can be read from a specific section(s) of a=
=20
file or writen directly in the recipe. What kind of other option is there?
if isn't any other exotic way, we can do that (by reading the sections@fil=
es=20
or the dirs list in the recipe )
Unless the user doesn't want to include the collection with the backup. =20
backing up a few mb of config files or several gb of files must be taken in=
=20
account. maybe present to the user the decision, showing the dirs size?
* we also should check for doubled entries.=20
ex: amarok uses the same folder as quod libet as their collection. if both=
=20
have the option of backing up the dirs, we have to have some sort of inner=
=20
storage and associate that to both apps.=20
b) i still don't get the point of asking the authors to script something fo=
r=20
us. what could they script? (that we can't in advance)
c) not only that, but if the file is on a mounted partition. on restoring =
the=20
files, if the dir is not there, should we read fstab and advise the user t=
o=20
mount it? Only then do what Toke proposed: asking the user for a new path?
> (This problem is starting to look interesting... ^_^ )
indeed :D
Regards,
Pedro.
Em Quinta 01 Novembro 2007, Daniel Fernandez escreveu:
> On Thursday 01 November 2007 13:48:39 Ivan =C4=8Cuki=C4=87 wrote:
> > > I mean: you can backup data in ${XDG_MUSIC}, this means also unpack
> >
> > That would mean that users WILL KEEP the music in the XDG specified
> > directory. I don't think that they [all] will.
>
> Maybe that's what they meant when said it would need scripting, byt
> scripting is just one way to solve that problem.
>
> Lets look to an example: User want to backup Amarok and their music
> collection.
>
> Sure, downloaded podcast are on .kde/share/apps/amarok/(...blabla...). But
> the music collection may be anywhere in their folder tree. If their distro
> works like *buntu and makes some ~/Music folder by default (**AND** the
> user keeps using that folder for their music, and that's a big "and") the
> backup "recipe" can be attacked with the current format.
>
> But in real world, users don't always use that folder. Me myself have mus=
ic
> files anywhere from "~/Music" to "/repository/music"
> to "/home/invitado/musica" to... hell, I even have
> a "/mnt/network-storage/delete-if-space-is-needed/music" folder with half
> a gibabyte of podcasts!
>
> That meas, in the "backup recipe" files we should be able to:
> a) include application generated subfiles, so the applications could upda=
te
> (through a standar library, if possible) where they keep their files (in
> our example, any time amarok updates their database, they update a file
> telling what files/folders it has defined as the music collection.
> b) include some kind of scripting language to make decisions, check for
> file existence, etc
> c) make the backup able to work with simbolic links, and let the
> application link on a folder anything that wants backed up. Kamion then
> should check where the symbolic link goes, so it could figure up where the
> file should be restored later.
> d) a combination of 2 or all 3 of those.
>
> (This problem is starting to look interesting... ^_^ )
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Kamion2-devel mailing list
> Kam...@li...
> https://lists.sourceforge.net/lists/listinfo/kamion2-devel
|
|
From: Daniel F. <net...@to...> - 2007-11-01 13:09:19
|
On Thursday 01 November 2007 13:48:39 Ivan =C4=8Cuki=C4=87 wrote:
> > I mean: you can backup data in ${XDG_MUSIC}, this means also unpack
>
> That would mean that users WILL KEEP the music in the XDG specified
> directory. I don't think that they [all] will.
Maybe that's what they meant when said it would need scripting, byt scripti=
ng=20
is just one way to solve that problem.
Lets look to an example: User want to backup Amarok and their music=20
collection.
Sure, downloaded podcast are on .kde/share/apps/amarok/(...blabla...). But =
the=20
music collection may be anywhere in their folder tree. If their distro work=
s=20
like *buntu and makes some ~/Music folder by default (**AND** the user keep=
s=20
using that folder for their music, and that's a big "and") the=20
backup "recipe" can be attacked with the current format.=20
But in real world, users don't always use that folder. Me myself have music=
=20
files anywhere from "~/Music" to "/repository/music"=20
to "/home/invitado/musica" to... hell, I even have=20
a "/mnt/network-storage/delete-if-space-is-needed/music" folder with half =
a=20
gibabyte of podcasts!
That meas, in the "backup recipe" files we should be able to:
a) include application generated subfiles, so the applications could update=
=20
(through a standar library, if possible) where they keep their files (in ou=
r=20
example, any time amarok updates their database, they update a file telling=
=20
what files/folders it has defined as the music collection.
b) include some kind of scripting language to make decisions, check for fil=
e=20
existence, etc
c) make the backup able to work with simbolic links, and let the applicatio=
n=20
link on a folder anything that wants backed up. Kamion then should check=20
where the symbolic link goes, so it could figure up where the file should b=
e=20
restored later.
d) a combination of 2 or all 3 of those.
(This problem is starting to look interesting... ^_^ )
|
|
From: Toke <to...@to...> - 2007-11-01 12:58:01
|
On Thursday 01 November 2007, Luca Bellonda wrote:
> I mean: you can backup data in ${XDG_MUSIC}, this means also unpack
> them in current Music dir wathever it is into destination system when
> you esport (or KDE_MUSIC_DIR or specific appplication, data
> directory), but you can't create directories, assign them permissions
> and so on while restoring.
As I see the use case for Amarok, their problem is that if they want to backup
the users music, they cannot specify the directory before the backup actually
takes place, since the location of the music library can be configured by the
user at runtime.
I suppose this could be solved by supporting some sort of, in lack of a better
term, "script-assisted" directory selection. I.e. in the recipes, there could
be a way to specify that the application wants to include certain
directories, and that the actual directory names should be obtained by
running a script (which would then also be provided). This script could then
pop up a dialog asking the user which part(s) of their music library they
want to export.
This leaves the problem of restore -- i suppose this could be solved by
prompting the user where they want to put the music files if the original
directory does not exist/is not writable/etc.
Oh, and I agree that the <dir> and <(in|ex)clude> tags make more sense.
Cheers,
-Toke
|
|
From: Ivan <iva...@gm...> - 2007-11-01 12:48:13
|
> I mean: you can backup data in ${XDG_MUSIC}, this means also unpack
That would mean that users WILL KEEP the music in the XDG specified directo=
ry.=20
I don't think that they [all] will.
=2D-=20
I am a spokesman for a better way of living
Love is the word and it can be heard
If you are young the message can be sung
-- Deep Purple
|
|
From: Luca B. <lbe...@gm...> - 2007-11-01 12:40:39
|
MjAwNy8xMS8xLCBJdmFuIMh1a2nmIDxpdmFuLmN1a2ljK2tkZUBnbWFpbC5jb20+Ogo+ID4gPiBo b3dldmVyIGxpa2VkIHRoZSBpZGVhLCBidXQgZm9yIHRoZWlyIHVzZWNhc2UgaGF2aW5nIHNjcmlw dGluZyBpcyBhIG11c3QsCj4gPiBJIGFtIHdvcmtpbmcgb24gc2NyaXB0aW5nIHRvbywgdG8gaW1w b3J0IHJlY2lwZXMgd2hpbGUgaW5zdGFsbGluZwo+ID4gcHJvZ3JhbXNzLgo+IEkgdGhpbmsgdGhh dCB0aGV5IG1lYW4gc2NyaXB0aW5nIGluIHRoZSByZWNpcGVzLi4uCj4KSSB0aGluayB0aGV5IHdh bnQgdG8gc3BlY2lmeSB3aGVyZSB1c2VyIGRhdGEgYXJlLiBGb3IgdGhpcywgdHJ1ZQpzY3JpcHRp bmcgaXMgbm90IG5lY2Vzc2FyeS4KVXNpbmcgWERHL0tERSBzdGFuZGFyZHMgaW4gcmVjaXBlcyBj b25maWd1cmF0aW9uIGZpbGVzICB3b3VsZCBiZQpzdWZmaWNpZW50LCBlbHNlIHdlIGNhbiBpbmNs dWRlIHNvbWUgc29ydCBvZiBtYWtlZmlsZSBwcm9jZXNzaW5nLCBidXQKdGhpcyBjYW4gbGVhZCB2 ZXJ5IGZhciB0byBiZSBjb21wYXRpYmxlIG9uIHZlcnkgZGlmZmVyZW50CmRpc3RyaWJ1dGlvbnMg YW5kIGVudmlyb21lbnRzIGZvciBhIHNpbXBsZSBiYWNrdXAgdG9vbCwgZXZlbiBpZiB0aGUKaWRl YSBpcyBmYXNjaW5hdGluZy4KCkkgbWVhbjogeW91IGNhbiBiYWNrdXAgZGF0YSBpbiAke1hER19N VVNJQ30sIHRoaXMgbWVhbnMgYWxzbyB1bnBhY2sKdGhlbSBpbiBjdXJyZW50IE11c2ljIGRpciB3 YXRoZXZlciBpdCBpcyBpbnRvIGRlc3RpbmF0aW9uIHN5c3RlbSB3aGVuCnlvdSBlc3BvcnQgKG9y IEtERV9NVVNJQ19ESVIgb3Igc3BlY2lmaWMgYXBwcGxpY2F0aW9uLCBkYXRhCmRpcmVjdG9yeSks IGJ1dCB5b3UgY2FuJ3QgY3JlYXRlIGRpcmVjdG9yaWVzLCBhc3NpZ24gdGhlbSBwZXJtaXNzaW9u cwphbmQgc28gb24gd2hpbGUgcmVzdG9yaW5nLgoKYnllCgpsYgo= |
|
From: Ivan <iva...@gm...> - 2007-11-01 12:17:59
|
> > however liked the idea, but for their usecase having scripting is a mus=
t,
> I am working on scripting too, to import recipes while installing
> programss.
I think that they mean scripting in the recipes...
=2D-=20
Sanity is the trademark of a weak mind.
-- Mark Harrold
|
|
From: Luca B. <lbe...@gm...> - 2007-11-01 12:12:47
|
2007/11/1, Ljubomir Simin <lju...@gm...>: > however liked the idea, but for their usecase having scripting is a must, I am working on scripting too, to import recipes while installing programss. > since music collections on different machines are rarely on the same path. Maybe remappping configure paths into user files while restoring is not a bad idea, but there must be a standard. Should we take into account XDG or KconfigDir manipulating user data ? > KOffice developers liked our tool as well, but they have some complains, all > contained in forwarded message. I will read it > PS. Should I crosspost to our mailinglist next time I talk to app developers > in order to keep the discussion open, or do you prefer me just "dumping" the > results, like now? In my opinion, more informations=>more ideas, you can post without problems. > * I suggest having a <dir> tag instead of a <file>*</file> which IMO is just > confusing. I did't pay so much attention to this side of the program. bye Luca Bellonda |
|
From: Ljubomir S. <lju...@gm...> - 2007-11-01 11:40:42
|
Hi, I talked with some app developers. Digikam ones haven't responded at all, and I'm still waiting for the kde edu and games people to reply. Amarok devs however liked the idea, but for their usecase having scripting is a must, since music collections on different machines are rarely on the same path. KOffice developers liked our tool as well, but they have some complains, all contained in forwarded message. Cheers! PS. Should I crosspost to our mailinglist next time I talk to app developers in order to keep the discussion open, or do you prefer me just "dumping" the results, like now? -- Ljubomir Simin Registered Linux User #351181 |
|
From: Luca B. <lbe...@gm...> - 2007-10-23 22:28:29
|
Only to let you know I am refactoring kamion-tools to implement new functionality and adding some automated tests via python program. kamion-tools is not yet in working state, for now. bye lb |
|
From: Luca B. <lbe...@gm...> - 2007-10-15 22:40:34
|
I uploaded new version with configuration variables in the CMakeLists.txt. We have two different configuration systems and default locations: one for kde4 gui and another one for general purpose libraries so I am not satisfied with default values and scripts to extract messages, but now I can work on it. I prefer to have 3 po files, one per project, if the user has the option to install or configure every project on his own. Can someone take a look in the lb-branch? Is there someone ready to work on gui/console code? bye to all. Luca Bellonda |
|
From: Ivan <iva...@gm...> - 2007-10-06 22:46:23
|
> Allright. One more question: who will distribute app recipes? Are they > going to be bundled with kamion, or should apps install them in some > specific place? Applications will do that - that will be indication which apps are installe= d=20 on the system. The location is configurable. We could write a cmake macro=20 that would install the files in the right place. =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: Ljubomir S. <lju...@gm...> - 2007-10-06 22:14:48
|
On Friday 05 October 2007 09:51, Ivan =C8uki=E6 wrote:
> > Yes, but for this we need the applications developers collaboration.
>
> We do not have the support in the libs for the translated resource names.=
=2E.
> so it's not only a job for them.
>
> > For example how to configure options to pass to compiler, used in a
> > subdir (a library) in the top directory in the configuration phase.
> > Anyway this is only a detail, I have to learn from others projects
> > using CMake.
>
> You already have that in 'root' CMakeLists.txt
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${KDE4_ENABLE_EXCEPTIONS}")
> you can add whatever you want. Why do you need the extra flags?
>
> > structure is changed. I would like that new code will be put in this
> > branch to avoid new refactoring. Later, eventually, we'll rename the
> > directory. I started from the source tarball on the download page and
> > not from the svn copy.
>
> If you want the development to be done on that code, it should be the
> trunk. I have tagged the current trunk as tags/base, so that we have that
> 'mark', and you can commit the changes to the trunk.
>
> > It's chicken and egg problem. If we have no working code, nobody will
> > care about us.
>
> Like I said, the code is not a problem - it works, it now has to be
> polished, and to add new features, and maybe, some things reimplemented
> (but that will not change the 3rd party devs view of Kamion)...
>
>
> @Ljubomir
> You can go with the current features and ask the devs if they would like
> something else to be added for the next version of the recipe
> specification.
>
> The thing that you could mention is that this is not kamion-only meta-inf=
o.
> It could be used for automatic generation of AppArmor/SELinux policies...
>
> Cheers
Allright. One more question: who will distribute app recipes? Are they goin=
g=20
to be bundled with kamion, or should apps install them in some specific=20
place?
=2D-=20
Ljubomir Simin=20
Registered Linux User #351181
http://counter.li.org
|
|
From: Ivan <iva...@gm...> - 2007-10-05 07:49:35
|
> Yes, but for this we need the applications developers collaboration.
We do not have the support in the libs for the translated resource names...=
so=20
it's not only a job for them.
> For example how to configure options to pass to compiler, used in a
> subdir (a library) in the top directory in the configuration phase.
> Anyway this is only a detail, I have to learn from others projects
> using CMake.
You already have that in 'root' CMakeLists.txt
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${KDE4_ENABLE_EXCEPTIONS}")
you can add whatever you want. Why do you need the extra flags?
> structure is changed. I would like that new code will be put in this
> branch to avoid new refactoring. Later, eventually, we'll rename the
> directory. I started from the source tarball on the download page and
> not from the svn copy.
If you want the development to be done on that code, it should be the trunk=
=2E I=20
have tagged the current trunk as tags/base, so that we have that 'mark', an=
d=20
you can commit the changes to the trunk.
> It's chicken and egg problem. If we have no working code, nobody will
> care about us.
Like I said, the code is not a problem - it works, it now has to be polishe=
d,=20
and to add new features, and maybe, some things reimplemented (but that wil=
l=20
not change the 3rd party devs view of Kamion)...
@Ljubomir
You can go with the current features and ask the devs if they would like=20
something else to be added for the next version of the recipe specification.
The thing that you could mention is that this is not kamion-only meta-info.=
It=20
could be used for automatic generation of AppArmor/SELinux policies...
Cheers
=2D-=20
Sanity is the trademark of a weak mind.
-- Mark Harrold
|
|
From: Luca B. <lbe...@gm...> - 2007-10-04 22:16:15
|
> application resources need to be i18nized. The application name and > description i18n strings could be loaded from .desktop files (if they exist > for the specified applications), but we still need a resource name > translations... Yes, but for this we need the applications developers collaboration. > State what the problem is. For example how to configure options to pass to compiler, used in a subdir (a library) in the top directory in the configuration phase. Anyway this is only a detail, I have to learn from others projects using CMake. > > open a branch on sourceforge svn next week? > Well, that's the main reason it exists, so go ahead! :) I created branches sub dir and an *experimental* lb-branch. The sources are compiling against latest KDE4 version (changed K3Icon::Desktop to KIconLoader::Desktop) You all are invited to look at the i18n of code and UI. I changed UI to separate complex HTML and CSS rendering from text. Directory structure is changed. I would like that new code will be put in this branch to avoid new refactoring. Later, eventually, we'll rename the directory. I started from the source tarball on the download page and not from the svn copy. > >We have to exit with a working program. > It's not the code that is problem. We could release a 1.0, but if there is no > support from the application developers, kamion is just a vaporware. It's chicken and egg problem. If we have no working code, nobody will care about us. My next step is fully automate i18n. bye Luca Bellonda PS: I found an article about kamion in Linux Pro Italian maganine July 2007, I suppose that is a translation. |
|
From: Toke <to...@to...> - 2007-10-03 21:46:00
|
> I hope that you all had the time to familiarize with the codebase, so we > can come up with the plan. I thought I'd give an update on my current status. I have finally managed to setup a KDE4 development environment and get kamion to compile (after fixing a small bug related to a refactoring of kdelibs - yay). I've poked around in the GUI code a bit, and I think i have a rough idea of how the different parts fit together, etc. I still need to get a better understanding of how the library works, though. I realise this is not particularly impressive progress, but I've got quite a list of things I need to take care of and be involved in ATM, unfortunately. Hopefully I'll get some time during the weekend to look closer at the codebase. Cheers, -Toke |
|
From: Ljubomir S. <lju...@gm...> - 2007-10-03 20:28:09
|
On Wednesday 03 October 2007 09:03, Ivan =C8uki=E6 wrote: > > I think that we ought to have 1.0 version ready at KDE4 exit. It > > doesn't matter if the library is not yet GNOME compatible. We have to > > exit with a working program. > > It's not the code that is problem. We could release a 1.0, but if there is > no support from the application developers, kamion is just a vaporware. > > Cheers As this is mostly my job, I feel obligated to inform you that by the end of= =20 the week I should have most of my faculty issues resolved, so I'll be able = to=20 do my work ;). And I'll probably need to know: a) Our release plan b) Features which we can offer to the app developers by, say, KDE4.0. c) Something else? I hope that you all had the time to familiarize with the codebase, so we ca= n=20 come up with the plan. Regards, =2D-=20 Ljubomir Simin=20 Registered Linux User #351181 http://counter.li.org=20 |
|
From: Ivan <iva...@gm...> - 2007-10-03 07:02:07
|
> kamion-gui, libkamion and kamion tools are i18nized, even if I have Well, just partially. libKamion's main problem concerning i18n is that=20 application resources need to be i18nized. The application name and=20 description i18n strings could be loaded from .desktop files (if they exist= =20 for the specified applications), but we still need a resource name=20 translations... > files. Now I have no time to learn very well cmake, so I need some > help to proceed. State what the problem is. > Directories structure is changed to reflect the various project needs. > Ivan, could you take a look to the new directory structure? You It's fine by me.=20 > open a branch on sourceforge svn next week? Well, that's the main reason it exists, so go ahead! :) > I think that we ought to have 1.0 version ready at KDE4 exit. It > doesn't matter if the library is not yet GNOME compatible. We have to > exit with a working program. It's not the code that is problem. We could release a 1.0, but if there is = no=20 support from the application developers, kamion is just a vaporware. Cheers =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-10-02 22:03:41
|
This is the actual situation for me: kamion-gui, libkamion and kamion tools are i18nized, even if I have not used semantic marking (this can be a next step). I have to write scripts to generate supported language directories and files. Extract messages scripts are working, but I have to refactor them. I am still having problems (caused by my ignorance) with cmake. The projects are compiling but i have some difficulty with configuration files. Now I have no time to learn very well cmake, so I need some help to proceed. Directories structure is changed to reflect the various project needs. Ivan, could you take a look to the new directory structure? You already have a snapshot, now I have modified kamion-tools too. Can I open a branch on sourceforge svn next week? Libkamion and kamion-tools use gettext directly to be QT independent in the future. >From new branch opening, the updates to the code and user interface should take i18n into account. I think that we ought to have 1.0 version ready at KDE4 exit. It doesn't matter if the library is not yet GNOME compatible. We have to exit with a working program. That's all for now. bye Luca Bellonda |
|
From: Ivan <iva...@gm...> - 2007-09-28 23:18:23
|
> Well, I for one am much more comfortable using SVN instead of CVS... But I > suppose I could learn CVS if required to... Ok, I'll switch it to SVN tomorrow (later today, to be exact).=20 |
|
From: Toke <to...@to...> - 2007-09-28 22:33:22
|
> Ok, do we need SVN instead of CVS (now that I've already uploaded the code > to CVS) Well, I for one am much more comfortable using SVN instead of CVS... But I suppose I could learn CVS if required to... -Toke |
|
From: Ivan <iva...@gm...> - 2007-09-28 17:05:13
|
> I thought they announced switching to svn long time ago.
Bummer, the CVS is activated by default, and SVN can be activated in admin=
=20
panel... they're insane :)
Ok, do we need SVN instead of CVS (now that I've already uploaded the code =
to=20
CVS)
=2D-=20
The bleeding hearts and artists,
Make their stand.
-- Pink Floyd
|
|
From: Ljubomir S. <lju...@gm...> - 2007-09-28 16:59:11
|
On Friday 28 September 2007 17:44, Ivan =C8uki=E6 wrote: > The code is now on SF's CVS so you all can play. If you're doing something > grand, you can create a branch for that - for experiments - until we deci= de > the road we're taking. > > Well, I was a bit shocked to find out that sf still uses cvs, and not > svn... I thought they announced switching to svn long time ago. =2D-=20 Ljubomir Simin=20 Registered Linux User #351181 http://counter.li.org=20 |
|
From: Ivan <iva...@gm...> - 2007-09-28 15:42:40
|
The code is now on SF's CVS so you all can play. If you're doing something=
=20
grand, you can create a branch for that - for experiments - until we decide=
=20
the road we're taking.
Well, I was a bit shocked to find out that sf still uses cvs, and not svn...
=2D-=20
The bleeding hearts and artists,
Make their stand.
-- Pink Floyd
|