I don't know why I have not seen anyone else having this issue. Maybe it is something that was introduced in a 3.5 point release, and since the 'check for updates' doesn't work in Rev for Linux, maybe no-one is using this particular point release
I downloaded a trial of the latest release of Rev enterprise (3.5gm2) to see if it was working any better now than this time last year. With Mandriva 2009.1, the menus are borked (when the mouse moves over them they wash out in dark blue, and are unreadable). On Ubuntu 9.04 this problem does not occur, so at least I could try and use Rev on linux.
However there was a further issue on both installations. The Tools palette has no button for the pointer tool, only a button for the browse tool, which means one can point at objects, but one can't select them to inspect them or script them. (Well, one can if one uses the menus to switch between browse and point, but many new users might not realise that).
At first I thought it was another graphical defect, since the Application Browser showed there was a pointer tool button grouped along with the browse, but there was no pointer button displayed. Finally I realised that the problem was because the pointer tool was located in an area not covered by the rect of the palette (hence it was effectively "off-screen").
So for anyone trying LInux, and confused about how to actually select things in order to inspect or script them, this will reveal the pointer tool button:
put "btn id 1945 of stack revTools" into tPointerTool
put "btn id 1944 of stack revTools" into tBrowserTool
set the rect of tPointerTool to the rect of tBrowserTool
select tPointerTool and tBrowserTool
set the left of tPointerTool to the right of tBrowserTool
select empty
put "done"
In order to run this code you will need to switch the message box stack between the single-line and the multi-line display (click the 2nd icon to the left in the MB window). Paste the code into the top box in the multi-line display, then whilst the cursor is still in that box press the 'enter' key.
Warning: my latest laptop labels both the return key and the enter key as enter. If the above code does not work (the word "done" does not appear in the lower part of the message box), then you may only have a return key. The enter key can be invoked by pressing the ctrl key + return key at the same time.
I hope that is of help to someone trying out Rev on Linux.
tools palette defect in Rev 3.5
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
{text within curly brackets added to clarify that gm1 was downloadable last week, not in the month of May}
I don't find explanations like that satisfactory.
I know it is a double-edged sword that the IDE is almost entirely alterable by users, but I had done nothing except unzip the file provided by runrev and copied it to another location on the file system. After entering the unlock code I started the backdrop, and saw immediately on moving the mouse over the menus that it was going to be hopeless working with Rev in Mandriva. I then proceeded to post a bug report with screenshots. It was only after I'd taken a few screenshots that out of the corner of my eye I noticed something wrong with the tools palette. Anyone who wishes can see those screenshots as attacted to this bug report: http://quality.runrev.com/qacenter/show_bug.cgi?id=8223, and I then posted a subsequent bug report about the palette defect. Knowing it might take months or years for Runrev to address the defect, I decided to post a solution here to help anyone else who runs into this. I feel like that was a waste of time, if it is fluke that only hit me. However, after spending years doing IT support, I don't like mysterious explanations.
I just don't see how the actions involved with unzipping a file could end up altering the bits in such a way that the alterations made enoug sense to Rev's engine to move a button off-screen. I suppose it is a logical possibility, but seems highly improbable.
Anyway, to test your theory, I downloaded Rev again, and went through exactly the same steps as before. This time, the tools palette was fine.
I remembered that since I had suspected that I might have to go through several distributions before I found one that Rev worked on, I'd written the original zip file to cd. I now unzipped that and installed it, and lo and behold, the tools palette from that zip file has the missing pointer button.
I'm happy now that we at least have a reproducible situation. But how to explain the difference between these zip files? They are clearly not the same file:
[bernard@localhost ~]$ md5sum downloads/linux/RevEnt350Full.zip
0562d2f9d8e09f75cb0880abcf53391f downloads/linux/RevEnt350Full.zip
[bernard@localhost ~]$ md5sum /media/cdrom/RevEnt350Full.zip
23c6a976705ae1134ae869394a68b8a8 /media/cdrom/RevEnt350Full.zip
The latter is the one I downloaded on 14th May and wrote to cd.
I unzipped both files in order to see what the internal differences are. And this most probably is the explanation. The file from 14th {of August} may contains gm1, whilst the one I downloaded today contains gm2.
Now the question is why their webserver is distributing different versions of Revolution with the same file name. That should only happen around the crossover date for a new release. Yet it must be months since gm2 came out. Of course the IDE Change Log file contains no mention of this defect, and additionally contains no dates. Yet clearly there was a change to the tools stack between these versions.
Whatever the explanation, it's wasted hours of my time finding out why my install had a missing pointer button from the start. Clearly gm1 was released with a faulty tools stack since that is what I downloaded 5 days ago. And it looks as though gm1 may have been the version distributed until I posted my bug report, then it was silently replaced with gm2.
Bernard
I don't find explanations like that satisfactory.
I know it is a double-edged sword that the IDE is almost entirely alterable by users, but I had done nothing except unzip the file provided by runrev and copied it to another location on the file system. After entering the unlock code I started the backdrop, and saw immediately on moving the mouse over the menus that it was going to be hopeless working with Rev in Mandriva. I then proceeded to post a bug report with screenshots. It was only after I'd taken a few screenshots that out of the corner of my eye I noticed something wrong with the tools palette. Anyone who wishes can see those screenshots as attacted to this bug report: http://quality.runrev.com/qacenter/show_bug.cgi?id=8223, and I then posted a subsequent bug report about the palette defect. Knowing it might take months or years for Runrev to address the defect, I decided to post a solution here to help anyone else who runs into this. I feel like that was a waste of time, if it is fluke that only hit me. However, after spending years doing IT support, I don't like mysterious explanations.
I just don't see how the actions involved with unzipping a file could end up altering the bits in such a way that the alterations made enoug sense to Rev's engine to move a button off-screen. I suppose it is a logical possibility, but seems highly improbable.
Anyway, to test your theory, I downloaded Rev again, and went through exactly the same steps as before. This time, the tools palette was fine.
I remembered that since I had suspected that I might have to go through several distributions before I found one that Rev worked on, I'd written the original zip file to cd. I now unzipped that and installed it, and lo and behold, the tools palette from that zip file has the missing pointer button.
I'm happy now that we at least have a reproducible situation. But how to explain the difference between these zip files? They are clearly not the same file:
[bernard@localhost ~]$ md5sum downloads/linux/RevEnt350Full.zip
0562d2f9d8e09f75cb0880abcf53391f downloads/linux/RevEnt350Full.zip
[bernard@localhost ~]$ md5sum /media/cdrom/RevEnt350Full.zip
23c6a976705ae1134ae869394a68b8a8 /media/cdrom/RevEnt350Full.zip
The latter is the one I downloaded on 14th May and wrote to cd.
I unzipped both files in order to see what the internal differences are. And this most probably is the explanation. The file from 14th {of August} may contains gm1, whilst the one I downloaded today contains gm2.
Now the question is why their webserver is distributing different versions of Revolution with the same file name. That should only happen around the crossover date for a new release. Yet it must be months since gm2 came out. Of course the IDE Change Log file contains no mention of this defect, and additionally contains no dates. Yet clearly there was a change to the tools stack between these versions.
Whatever the explanation, it's wasted hours of my time finding out why my install had a missing pointer button from the start. Clearly gm1 was released with a faulty tools stack since that is what I downloaded 5 days ago. And it looks as though gm1 may have been the version distributed until I posted my bug report, then it was silently replaced with gm2.
Bernard
Thanks for confirming that, Mark. When I installed what should have been gm2 and saw the defective menus and the defective tools palette I was dismayed. When you said it was fine for you on Ubuntu, I thought I might be going insane.
I do at least have an install in a VM that looks ok. Hopefully I will find it stable enough in Linux over the next few weeks that I can justify upgrading to enterprise once again.
Bernard
I do at least have an install in a VM that looks ok. Hopefully I will find it stable enough in Linux over the next few weeks that I can justify upgrading to enterprise once again.
Bernard