OLD - FET-5.24.0 snapshot available

[Liviu Lalescu]

I have put this new snapshot. From the ChangeLog:

   - Code improvement in reading the .fet XML files: converted from the obsolete Qt classes QDom* to QXmlStreamReader. It might
   bring a speed and memory improvement when reading the input file, and ensures FET source compatibility with future Qt versions.
   Also error reporting when reading a corrupt file is improved.
   - It is now allowed to have constraints preferred/home rooms with a single room (suggested by liquid and Volker Dirr).
   - Added a new example file from Vietnam, by nguyenhuuduyet.

Please test the new preferred rooms with a single room and the XML improvement by opening and saving your file and comparing by contents, it should remain the same. Also, generate on it.

The link, as usual, http://lalescu.ro/liviu/fet/download/test/

If everything goes well, the release will be probably in 1-2 weeks.

[vanyog]

There are many files without extensions in src\interface directory or with shortened names. For example:
addconstraintactivitiesendstudentsdayform_templa
addconstraintactivitiesmaxsimultaneousinselected
addconstraintactivitiesnotoverlappingform_templa
addconstraintactivitiesoccupymaxdifferentroomsfo
...
What are these files for?

[Liviu Lalescu]

I have released a new snapshot, with minor code bug fixes.

There are many files without extensions in src\interface directory or with shortened names. For example:
addconstraintactivitiesendstudentsdayform_templa
addconstraintactivitiesmaxsimultaneousinselected
addconstraintactivitiesnotoverlappingform_templa
addconstraintactivitiesoccupymaxdifferentroomsfo
...
What are these files for?

You need to use official tar/bzip2, like: "tar -jxvf fet-5.23.4.tar.bz2". Or, under Windows, I unpack to tar with 7-zip and unpack the tar with Total Commander.

[Liviu Lalescu]

I released a new snapshot, minor changes.

[vanyog]

Without a version control system is difficult to keep track of changes made by more then one developers.

Twice I tried to merge your daily snapshots with the changes I offered. It took me much time to find differences between the files I changed and the files in your snapshots. The result of this now is here: https://github.com/vanyog/FET but I can not be shore that some of changes you made are not missed.

I was enthusiastic to give some help, but I can not spend hour of time for work that could be done by several clicks.

If some new ideas come to me I will share but if you revise your position about usage of version control systems your collaboration with other developers will be much more efficient.

[Volker Dirr]

Hallo vanyog,

it is not difficult if you use a tool like kdiff3:
http://kdiff3.sourceforge.net/

[vanyog]

It's true. It is not hard by Kdiff3 to compare 2 directories or 2 files. But this is a routine job that I have to repeat each time you publish a new snapshot of code. Each time I have to download an archive, extract files, compare directories, compare files, merge them. If your code was in a repository, all this work could be done by just one command from QtCreator's menu.

Are you interested the number of developers that work on FET project to grow? If you are, you have to think about how to make them feel more comfortable in this project and save their time and effort.

http://producingoss.com/en/technical-infrastructure.html

[Liviu Lalescu]

I have put a new snapshot, only minor changes to two strings.

[Volker Dirr]

of course version control system has advantages. i know.

you don't need to merge it every time. in fact you never need to merge, because only Liviu need to merge if he want to have it in official version. so it is only his problem. (it is max a problem if you want to code stuff that Liviu don't want to implement into official version, but in that case you might need forge code anyway. so again it doesn't matter much.)
even if you use a version control system you need/must decide if you want to merge or not.

i don't want to say version control system are bad, they have got nice advantages; but they also have at least 3 disadvantages:
- developers don't read and think carefully about changes if they are always merged automatically. critical side effect can happen much faster because of skipping reading and skipping talking to other developers.
- developers waste time, because they forgot to talk about goals (who is coding what? do all developers like the goal/target? did they talk about pro and cons of the target? no other currently coding that?)
- some developers (like me in the past) wouldn't help, because they need to learn how to use a version control system

You see: disadvantages like they happen with your code: you reimplemented a feature which was skipped because other users don't want it.
a version control system doesn't help much if developers don't talk to each others. of course in your example it wasn't critical, because just a few lines. but what if you have a nice idea and code it without talking to others? you might not see the problems for other users.
Liviu and me are several times on "other sides", because he think like a coder. I try to think more like a guy that work at school and need to use a timetable software. That are sometimes 2 totally different views on the program. But talking about that helped very much in developing and coding. It was and is good that we always talk about our ideas before we spent to much time into coding useless stuff.

of course you are also right: if there are many developers coding a version control system is of course useful/needed. but so far there are not many developers. (let me think: less then a fist full in around 10 years?)
also on github are FET uploads, but like you can see: they doesn't attact other developers :-(

but if it help you, we can think about this:
i upload by a version control system the official versions. so you can get the "official" FET versions.
Liviu can still work like we want. So he don't need to change anything in his way of coding.
And you will always have official versions.

[vanyog]

Thank you for your post Volker!

Your are right about many things.

Of course, Liviu will decide what change to accept and what to reject.

Of course, it is better for developers to discuss their plans first and start to write code after that, and coordinate who and what is doing.

It would be worthwhile to start to maintain a code repository only if you consider this important for the overall growth of FET project, but not just for me. I would like just to help but not to create more work to you.

You see, my suggestions are changes of just 2-3 lines of code. It's easier for me to code them right away than to explain what I want to suggest. These changes make the program more comfortable for me to start it and close it many times testing the translation of interface in Bulgarian. My be these changes are not important at all for other users. I apologize for I was a bit insistent.   

[Liviu Lalescu]

No problem 

You don't need to check your translation that often. You can also start two FET programs in parallel, one in English and one in Bulgarian.

I prefer to keep my work to a minimum. Maybe someone will come to create a FET interface using the FET engine; I may post a link to it on the FET homepage; if and when it will be better than the current FET interface, it might replace it.

[Liviu Lalescu]

I have put a new snapshot, minor improvement in the XML .fet file. Of course older files can be opened. Please test.

[Liviu Lalescu]

I have put a new snapshot, minor source cleanup.

[Liviu Lalescu]

I have released a new snapshot, minor improvement.

[Liviu Lalescu]

I have released a new snapshot, minor improvements (bugs found with an automatic tool).