Shoutbox

btw, such an email will actually not help at all...

And suggesting for sending such a mail actually shows you don't fully undersand the scope and difficulty of this though (no offense in the slightest way!!! it's just to say that it isn't that strait forward as many might think and assume).

Patchou (heck any programmer) would never be make something like that in a way so you can check ampersand collisions topic by topic. That is simply totally useless...

For example, the 'OK', 'Cancel' and 'Apply' buttons in the preferences must be checked against all controls in all the preference panels (!). Obviously you would never find the keys for the 'OK', 'Cancel' and 'Apply' buttons in each and every section. Thàt would be unlogical and way, waaaaaaay too useless. And this is just a very simply and small example as there are also much more and much more difficult to spot scenarios were some controls need to be checked against a multiple of other controls, which on their turn depend on the presence of other controls, etc and all across different sections thruout the entire translation (eg: some menu items in Plus!3 were used in different menus at the same time and it also depended on which version of Mesenger you used, etc).

In fact, when discussing/thinking about such an application you should forget the term "ini topic" and everything related (eg: "check collissions in topic"), as that is totally inrelevant with something like this.

I am aware of the standardbutton-issue 'OK', 'Cancel' etc... that would be a gap in such a ampersand collision-checker... and such issues could be solved by simply make a note about it like:

'You are about to apply an apersand that might be used by any OK, Cancel, Ignore etc-button. Do you want to skip this check or apply it on your own risk?'...

... that would be a workaround... the important thing is that the sections are similar to the visual image (the menus)... if so, details can be handled... (i think)

quote:

---

Originally posted by Kian
I am aware of the standardbutton-issue 'OK', 'Cancel' etc... that would be a gap in such a ampersand collision-checker... and such issues could be solved by simply make a note about it like:

'You are about to apply an apersand that might be used by any OK, Cancel, Ignore etc-button. Do you want to skip this check or apply it on your own risk?'...

---

Believe me, you do not know what you're up against and you would soon see that it is far from as easy as that when you make such a program.

The example of the OK, Cancel and Apply button is only one example out of the extremely long list of exactly the same issues. In fact the whole thing consists of situations like that.

The situation where you could check one ini topic and safely say you have checked all possible combinations is very very rare and almost doesn't exist.

quote:

---

Originally posted by Kian
... that would be a workaround... the important thing is that the sections are similar to the visual image (the menus)... if so, details can be handled... (i think)

---

Sections will never ever be similar to the visual image. This is simply not doable and as good as impossible.

Things like the OK, Cancel, Apply buttons are not "just a minor one-of-a-kind detail"; It happens in almost every panel, window and feature thruout Plus!.

As said, you simply can not think in terms of "checking ini topics" when dealing with something like this. An ampersand collision checking program doesn't care what key is in what topic. The only thing that is important is to know what other keys a certain key relates to; hence why the index file of your program will contain a list of all the keys a certain key must be checked against and that for almost every key which exists.

A program which depends on ini topics or which is based upon 'rules' will always seriously fail doing its job properly.

In fact the program on its own would be dead simply and should/will contain only a few lines of code. It is the time, effort and precision you need to put into creating and updating the index file which makes this so hard to pull of.


-----

Such a ampersand collision check program also even depends on how Plus! itself is actually programmed!

Take the panel "Conversations > Chat Logging" for example. There you can choose between HTML or textfile logging, and depending on which choice you've made a different set of radio controls is shown.

Currently Plus! is programmed in such a way that the control which you don't see still are loaded on the panel. This means that the ampersand are also present.

You can see this if you press ALT+P. You will notice that the "Prefix lines" option is NOT selected/unselected. This is because there is actuall another same control (the one from the other HTML/Text option which is hidden at the moment). Thus this other 'hidden' control has that very same ampersand and Windows simply cycles between them instead of clicking the control.

To see the difference press ALT+D and notice that Windows does check/uncheck the option to save logfiles.

If Plus! was programmed so that such hidden controls are in fact not loaded, the ampersand selecting would behave as you might aspect.

Nevertheless, can this be considered an ampersand collision? Yes, as the controls aren't selected when you press the ampersand. No, as pressing the ampersand for the other (hidden) controls do not influence those controls.

i never thought about the hiddens sides of Plus! - to me that sounds like you can accept hidden options by pressing they ampersands and then hit the Ok-button...

I do not agree with you. Well a little - of course you cant say its a collision if a menu has the same apersands as the hidden menu 'beneath' but still - thats not the essential... the essential is that a shortcut is created.
An example without any releation to reality:

If the shown menu has a radiobutton with the text

'&Enable Chatlogging'



and the hidden menu beneath has a checkbutton with the text

'Disable &emoticons for 7 seconds'


... it is correct that a collisionprogram will see this as a collision. But it dosnt matter! who cares if the program fix something that might be correct to something that still works... The program could easily fix the last sentence to:

'&Disable emoticons for 7 seconds'


... without problem... As long as the sections are structured as the visual 'image' (menu) i am almost certain that most of the problems in making a collision-checker is solved. Of course there is some exceptions like with the OK, Ignore, Cancel etc-buttons but i still claim that there is a work-around...


Prove me wront

quote:

---

Originally posted by Kian
I do not agree with you. Well a little - of course you cant say its a collision if a menu has the same apersands as the hidden menu 'beneath' but still - thats not the essential... the essential is that a shortcut is created.
An example without any releation to reality:

If the shown menu has a radiobutton with the text

'&Enable Chatlogging'

and the hidden menu beneath has a checkbutton with the text

'Disable &emoticons for 7 seconds'

... it is correct that a collisionprogram will see this as a collision. But it dosnt matter!

---

If that doesn't matter than any ampersand collision doesn't matter. The thing you just described is the whole essence of ampersand collisions.

quote:

---

Originally posted by Kian
who cares if the program fix something that might be correct to something that still works... The program could easily fix the last sentence to:

---

I hope you didn't just suggested to also make the program automatically fix collisions

For the sake of scope: if making a collision checking program is easy as hell, an auto-fixing program would be extremely difficult.

quote:

---

Originally posted by Kian
As long as the sections are structured as the visual 'image' (menu)

---

which will never ever be possible...

And imagine the size of the translation file needed if Plus! was created that way. It would be a hundred times bigger than it is now containing hundreds and hundreds of duplicated sections and keys.

quote:

---

Originally posted by Kian
Of course there is some exceptions like with the OK, Ignore, Cancel etc-buttons but i still claim that there is a work-around...

---

The OK/Cancel/apply is NOT an exception! That is the whole point. If it was "just an exception" then ok, it would be easy. But it isn't an exception, it is almost a rule of thumb. The exception would be the case where cross-topic collisions are not present.

-----------

Forget about "checking ini topics" or about a program which works almost automatically (given a few exceptions which need special attention).

An ampersand collision program will never ever work in that way.

You always will need an index file as I described earlier. It is impossible without it.

Easy tiggr... i am just trying to mess around with the idea... nothing else -

quote:

---

If that doesn't matter than any ampersand collision doesn't matter. The thing you just described is the whole essence of ampersand collisions.

---

I dont think you get my point. My point is that if two menus are placed on eachother like layers and only one of them is visible the collision-checker is still seeing collisions even though it isnt 'real' collisions. The difficult thing is that the program should know which menu/layer is visible. But still i claim that it dosnt matter! If two equal shortcuts are found - one in the hidden layer and one in the visible layer - it isnt a collision to you and me but it is to the program. But would you care about if the shortcut is changed to fit the program? I wouldnt care at all as long as the shortcut works and dosnt coalate (how do you 'bend' 'collision'?)
The point is: youre changing a shortcut/ampersand from being legal to legal - but only because the program dosnt know its already legal... the ampersand is moved but it is still working.
Infact thats a typical problem: computers cant think so we have to make workarounds so that they still do what we want - just from another view...

quote:

---

I hope you didn't just suggested to also make the program automatically fix collisions

---

I am aware of this: the collision-program fixes issues thats already okay... but as I said before: it is a typical OOP-problem - its almost impossible to get a computer to think the way we do and therefor stuff like this has to be done - it might seems like a awkward way but it is necessary and as long as the program dosnt mess up the ampersands its okay from my point of niew




And the last part of your post: I know it would mean that the structure should be completly re-designed... and so should Messenger Plus. Thats why i said that I was sad about that it wasnt done from the beginning. I see that the amount of the language-file will expand... i dont know - still i think that certain sections could be organized as they are today... like the standard-button-issue - no need to translate 50 'Cancel'-buttons.

And again: I am just thinking about it - messing around with the thoughts - but I know that Patchou has his reasons to do things the way he does... and I accept that... I am just thinking of how it could be done elsethen...

quote:

---

Originally posted by Kian
Easy tiggr... i am just trying to mess around with the idea... nothing else -

---

grrrrrawnn....  I'm easy though

quote:

---

Originally posted by Kian
I dont think you get my point. My point is that if two menus are placed on eachother like layers and only one of them is visible the collision-checker is still seeing collisions even though it isnt 'real' collisions.

---

It sure is in the way Plus! is programmed at the moment; As long as an option isn't ticked/unticked when you press an ampersand, but rather cycles thru the availbe options, then it is a collision, no matter how you try to interpret it.

In fact, the way it is programmed at the moment in Plus! can cause unwanted effects as you actually can change those 'hidden' controls by accident.

quote:

---

Originally posted by Kian
The difficult thing is that the program should know which menu/layer is visible.

---

No. The program doesn't need to know which layer is visible or what not. That is, it should depend on the special 'index' file, not on ini topics, not on visible layers or whatever else.

quote:

---

Originally posted by Kian
But still i claim that it dosnt matter! If two equal shortcuts are found - one in the hidden layer and one in the visible layer - it isnt a collision to you and me but it is to the program.

---

For me it sure is a collision as that is exactly what a collision is. An ampersand collides (with whatever) as long as it does not perform its duty. And that duty is ticking/unticking the control it is meant for.

It doesn't matter if that happens because of hidden controls or even another 3rd party which prevents the use of a certain shortcut key so to speak.

quote:

---

Originally posted by Kian
But would you care about if the shortcut is changed to fit the program? I wouldnt care at all as long as the shortcut works and dosnt coalate (how do you 'bend' collision'?)

---

collide

A collision is exactly that, the same ampersand used on different controls in the same focus. If it does that, the ampersand does NOT work. It doesn't matter if that other control is hidden or whatever, if the visible control is not ticked/unticked you have a collision.

quote:

---

Originally posted by Kian

quote:

---

I hope you didn't just suggested to also make the program automatically fix collisions

---

I am aware of this: the collision-program fixes issues thats already okay... but as I said before: it is a typical OOP-problem - its almost impossible to get a computer to think the way we do and therefor stuff like this has to be done - it might seems like a awkward way but it is necessary and as long as the program dosnt mess up the ampersands its okay from my point of niew

---

Some collisions might be intended though.

And a program should never auto-fix ampersand collisions as a program (like you rightfully put it) can't think as a human beeing.

Ampersands are (at least should be) placed with some logic behind it, not simply because some letters aren't available anymore.

This has been discussed also in the past though...

quote:

---

Originally posted by Kian
And the last part of your post: I know it would mean that the structure should be completely re-designed... and so should Messenger Plus. Thats why i said that I was sad about that it wasnt done from the beginning.

---

That is not the issue. It can NOT be done, even when done from the start...

quote:

---

Originally posted by Kian
I see that the amount of the language-file will expand... i dont know - still i think that certain sections could be organized as they are today... like the standard-button-issue - no need to translate 50 'Cancel'-buttons.

---

Not all cancel buttons are translated as "cancel" in some languages. In some languages it is more logical to translate it as "close" or "quit" or whatever so to speak depending on what dialog they're used on.

The reason why there are so many OK, Cancel, etc buttons is because those are different buttons on different dialogs all together.

In fact, this is a whole other issue than what I meant with duplicated stuff...

What you just describe is:

You have two totally different dialog windows with each an OK button. You could make the translation engine so that there is only 1 translation for the both of them. But this seriously decreases the the freedom of the translators. For a think like the OK button, this seems a bit useless, but consider controls with the same initial English translation "Contact List Viewer" on totally different dialog windows. It is quiet possible that on one dialog the translated text will fit, but on the other dialog it doesn't. Then what? You only have 1 string which you can translate, not two. So as translator you are forced to use the shortened version which will be used for both of them. Not to mention the thing I said above about how translations can be different for the same English version depending in what context and what dialog they are used on.


So, this is totally different than:

You have 1 dialog window like this:
---------------------------------
What do you want todo?
  [X] Go to &bed
  [  ] Go to &toilet
        [x] Give me a &pillow or: [x] Give me a &radio

[&OK]            [&CANCEL]
---------------------------------

When you select "bed" the seconday option "pillow" is shown and "radio" is not shown.
When you select "toilet" the secondary option "radio" is shown and "pillow" is not shown.

Now, "pillow" and "radio" can have the same ampersand as these options are not shown and used simultaniously (remember the chat logging panel in the Plus! preferences, its almost alike). Thus todo what you suggest, to make everything in topics as it is seen in real so one could easly check ampersand collisions, a translation file should look like this:

[Window.whattodo_1]
bed=Go to &bed
toilet=Go to &toilet
pillow=Give me a &pillow
OK=&OK
Cancel=&Cancel

[Window.whattodo_2]
bed=Go to &bed
toilet=Go to &toilet
radio=Give me a &radio
OK=&OK
Cancel=&Cancel

As you can see, many duplicated topics and keys will be nessecairy with this. Imagine that this isn't just 1 dialog we're talking about but hundreds of dialogs with quite often many many suboptions, subsuboptions, subsubsuboptions, etc.... just like Plus! and you would have an idea of the big mess and total uselessness it will create.

This is simply not doable, not now, not from the start of creating Plus!, never...

A decent translation file for the above must be like:

[Window.whattodo]
bed=Go to &bed
toilet=Go to &toilet
pillow=Give me a &pillow
radio=Give me a &radio
OK=&OK
Cancel=&Cancel

And it is up to the translator (and the AC-program) to know that "pillow" and "radio" can have the same ampersands.

For the AC-program, an index file must be made like this:

(to put it simply):
bed=toilet, pillow, radio, OK, Cancel
toilet=bed, pillow, radio, OK, Cancel
pillow=bed, toilet, OK, Cancel
radio=bed, toilet, OK, Cancel
OK=bed, toilet, pillow, radio, Cancel
Cancel=bed, toilet, pillow, radio, OK

each key which is read out contains a list of the other keys which needs to be checked against. Notice the lack of "pillow" in the "radio" key and vice versa. This makes that the program 'knowns' that "radio" and "pillow" can have the same ampersand as they are not checked against each other.

quote:

---

Originally posted by Kian
And again: I am just thinking about it - messing around with the thoughts - but I know that Patchou has his reasons to do things the way he does... and I accept that... I am just thinking of how it could be done elsethen...

---

I know but the point is it can NOT be done otherwise in a decent way....



--------------------

EDIT: @Kian: rofl at your reply... I know the feeling thank god that webcams don't automatically send pictures

@ZrednaZ: lol... well, you're actually right... need to cut down on lengthy posts

heh i thought i wrote so much you wouldnt answer - but i guess i was wrong. Sitting with hangovers is just not the best thing while trying to catch up your 'book-writings' -

I'll get back to you later - be aware

But for now I have spent 6 hours in boxers (yep! thats all i am wearing!), in front of my computer, without any meal or such... i havent had my daily shower and i havent been outside. I think I'll go grap a dinner downtown on a cafee - currently its 1747 and i am hungry.

Catch'a up later (tomorrow)


// peter

quote:

---

Originally posted by Kian
heh i thought i wrote so much you wouldnt answer - but i guess i was wrong.

---

Haha..
That's the thing about chatting with Cookie, you gotta choose your sentances carefully as he'll quote every single one explaining why it's accurate or inaccurate, effectively ending up with a relpy three times the length or your post. Write too much and you'll remain in front of your screen in your boxer shorts all day, trying to keep up while wondering where dinner time went, you don't want that.
This takes me back to the good old days in which our discussion about Choli's translator program took place...

Okay - I give up - this is going nowhere...

quote:

---

Originally posted by ZrednaZ

This takes me back to the good old days in which our discussion about Choli's translator program took place...

---

Link me up buddy - i wanna read that...