Nvu progress 20041215
By glazou on Wednesday 15 December 2004, 20:48 - Nvu - Permalink
The numbers make reference to Linspire's bugzilla. Any bug submitted through the "Bug report" menu item in Nvu goes to Linspire's QA, is verified by them, and filed if needed.
- 18494 add TM symbol to special chars dialog: fixed
- 18270 PHP processing-instructions incorrectly start with >? in 0.60: fixed (urggghhh)
- 18438 Publishing a doc fires a debug alert: fixed
- 18541 Saving or switching back from an updated source view takes too long: this is caused a little bit by the colored source view, and a lot by the Inline Spell Checker. I am working on a workaround, and sent Neil Deakin a message about it.
- 18519 Context-click on the last tab to close it leaves the tabeditor grey: fixed
- 18543 Context-menu gone from the site manager in 0.60: yes, absolutely. Not a priority.
- Editing the source view and switching back to normal does not clobber the original contents of the document: fixed
- Non localized strings in 0.60: the new NvuFR team sent me their list in a very well presented table and that saved me a lot of time. I am happy to report that 25% of the issues are already fixed.
- Delete file and Create directory functions horked in Site Manager (0.60-aviary): fixed
- directory mozilla/composer/locales: done
- I started an extensive cleanup of editor.xul, editorOverlay.xul, utilityOverlay.xul in order to trash all the useless bits and reduce the dependency to chrome://communicator/. That's a work in progress.
- Started working on the Mac specific bugs (need to force-quit, bad hiddenWindow.xul, incorrect shortcuts). Warning, this is done on my personal time so it goes slower than the rest. Plus the fact I am not a Mac expert...
- KDE default mimetype icons are now shown by the Site Manager if Nvu is built on linux with the corresponding option

Comments
Is there a way to access Linspire's Bugzilla? I tried Googling but got nowhere.
I had a bug similar to 18541 occuring, but the actual cause was that every time I switched back after saving from source the entire body of the page was doubled - i.e. the text and images all came twice. This was exponential (the doubling doubled), and I only realised when I saw the file size change, because the start of the page still looks identical. (I did report this, but via nvu -at- nvu -dot- com)
Just a little note, always make PHP start with <?php rather then <? because some people might not have short tags on.
Thanks.
I hate to sound like a broken record. I haven't seen anything recently regarding XHTML support. Is it dead? On life-support? Alive and well just waiting for the right time to appear?
Gary : XHTML support is planned.
Daniel , the important thing is to have a mac port be it a bit more buggier than the other is *not* a problem.
Just to confirm what Helgi said about <?php and <?
(if on, php *will* try to parse <?whatever - eg <?xml), so they really shouldn't be used...
- <?php is the recommended way
- the short_open_tags directive is *evil*
I hope my insistance doesn't sound rude, but this is very important...
Best regards,
Olivier
Why don't you use a Nvu progress like the one of Burning edge for FIrefox?
It would be more simple to follow the progress of development and the remaining bug to fix.
However, this is a minor thing. Great job!
Olivier and Helgi, while I agree that the proper and preferred method of starting php is <?php and not <?, there is *no* reason NVU should go in and manipulate my code. I'm not sure why NVU has code at all to mane any changes to the code that aren't explicitly ordered by the user, but if it's going to do this, it should at least avoid doing it to php code!
Charles: Ohh, NVU _changes_ code ? Was mostly talking about if say you make a new PHP document that you "auto" get a <?php at the start (A feature that should be able to turn off if existed, since anything predefined irritates some people, including me :P)
Olivier: Yeah short tags are evil indeed ;/
Helgi, Nvu makes all kinds of changes to the whitespace as an example, and in previous versions, everything contained in php tags was wiped out all together. All I'm saying is that the fundamental bug that should be fixed isn't the issues of a backwards '<', it's the issue of Nvu writing out *anything* to the files it opens.