Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ TheIDE » U++ TheIDE: CodeEditor, Assist++, Topic++ » Topic browser wishes [FEATURE REQUEST]
Topic browser wishes [FEATURE REQUEST] [message #518] Fri, 06 January 2006 22:42 Go to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
These missing features would be essential for a documentation browser:
- scrolling the text panel by keyboard
- copying selected text regions from the text panel
- search on current page
- search on all pages
- search by topic name

[Updated on: Wed, 03 May 2006 01:48] by Moderator

Report message to a moderator

Re: Topic browser wishes [message #519 is a reply to message #518] Fri, 06 January 2006 23:05 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I agree. I will try to fix that ASAP.
Re: Topic browser wishes [message #521 is a reply to message #519] Sat, 07 January 2006 11:54 Go to previous messageGo to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
Could you tell the benefits of using a proprietary tpp format for documentation instead of html? I think html docs would be much more accessible to users. They could choose their favourite web browser, which already has all the fancy features such as for example multiple tabs or mouse gestures. A docs browser could still be provided as an alternative, which has multi-page search.

[Updated on: Sat, 07 January 2006 11:54]

Report message to a moderator

Re: Topic browser wishes [message #522 is a reply to message #521] Sat, 07 January 2006 12:16 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Well, there of course is a lot of truth there...

However, whole thing begins with the QTF issue. In the beginning, we needed some rich-text format mainly to create reports of our database applications.

Well, real choices back then were:

- HTML
- RTF
- develop the format

Now:

HTML - problem is that HTML lacks complete typography, so it cannot be used there. It is also quite verbose and parsing is not trivial.

RTF - totally unusable if you are going to use it in code to create things (like programmatically create the table). Also, complete implementation is not trivial.

That left us (back then) with "develop the format".

Later we started to use the same format for e.g. dialog boxes (right now, almost any text in U++ GUI is QTF enabled - just prefix it with \1).

Even later we have created wordprocessor package and while it can in fact work with any format, QTF was the natural choice for the default one.

It is non-standard, but does its job very well.

QTF allows using Topic++ for creating application rich-text resources. Topic++ is multi-purpose tool; one of purposes is to create the help for the application or other document resources (like copyleft text in the About.. box of TheIDE). .tpp files can be directly compiled into the aplication, not external files are needed to ship with it (self-containment is one of goals we always tried to achieve with U++). See "reference/Topic" example.

As for HTML, the QTF->HTML conversion is trivial. The whole U++ website is generated by exporting .tpp files and all code documentation topics are there as well, so if you prefer HTML, just read the docs at the website.
Re: Topic browser wishes [message #548 is a reply to message #522] Sun, 08 January 2006 23:36 Go to previous messageGo to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
I have some wishes for the topic++ editor:
- provide the widespread alternative copy-paste keys: shift-del, shift-ins, and ctrl-ins
- multi step undo
- find & replace

These would be a big help for editing the documentation. For example when a single file contains multiple occurences of the same error, a find & replace would speed up the work of fixing them.
Re: Topic browser wishes [message #553 is a reply to message #548] Mon, 09 January 2006 08:24 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

>provide the widespread alternative copy-paste keys: shift-del, shift-ins, and ctrl-ins

absolutely!
Re: Topic browser wishes [message #554 is a reply to message #548] Mon, 09 January 2006 09:38 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
hojtsy wrote on Sun, 08 January 2006 17:36

I have some wishes for the topic++ editor:
- provide the widespread alternative copy-paste keys: shift-del, shift-ins, and ctrl-ins



Done - on uvs now (sorry, those we just forgot to add)

Quote:


- multi step undo
- find & replace

These would be a big help for editing the documentation. For example when a single file contains multiple occurences of the same error, a find & replace would speed up the work of fixing them.


If I understand you well, both are already there.... Undo IS multistep and find&replace is on Ctrl+F. Set selection to activate "replace in selection".
Re: Topic browser wishes [message #558 is a reply to message #554] Mon, 09 January 2006 09:51 Go to previous messageGo to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
Sorry, I thought that undo and find & replace is missing. The reason was that there is no menu entry for them. Now I see that toolbar icons are provided, but those are usually duplicated in menus, so I tend to check menus only. Another problem was that I use the Alt-Backspace for undo, which works in most applications, but not in Topic++ editor.
Re: Topic browser wishes [message #578 is a reply to message #518] Thu, 12 January 2006 21:46 Go to previous messageGo to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
Here is an other problem with the topic++ editor.
The character layout within a line is uneven and very strange to look at. See in the partial screenshot I am attaching, that in the same line the distance between characters are changing. This makes it hard to read the text, because it needs more concentration to identify the real spaces. Could you fix it to make the distances between neighbouring characters visually equal, and not changing on a page?
index.php?t=getfile&id=30&private=0
By the way how do I hide all those dots which are displayed for spaces? And could you please also make Alt-Backspace hotkey for Undo, just like in the code editor?

[Updated on: Thu, 12 January 2006 21:47]

Report message to a moderator

Re: Topic browser wishes [message #579 is a reply to message #578] Thu, 12 January 2006 22:42 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Actually, this is quite hard to fix, this is the result of "true wysiwyg".

The problem is that RichEdit (and RichText in this mode) are printing the text by downscaling it from its physical (printer) appearance. This unevitably leads to "uneven" layout of characters (it could be in theory resolved by subpixel resoltion, but that would make the text blurry, which is even worse I think).

Hm, maybe keeping "pixel" distances for words and fix them at spaces could help.... I will think about it.

(Just a note: Both MS Word and OpenOffice Writer share exactly the same problem. If you are doing wysiwyg, some characters will be one pixel off their ideal positions for given zoom factor).

Alt-Backspace was added on Tuesday (I think). Sync uvs Smile
Re: Topic browser wishes [message #580 is a reply to message #579] Fri, 13 January 2006 00:08 Go to previous messageGo to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
I copied together the same text & font as rendered by 1) RichText, 2) Ms Word, and 3) PhotoImpact.
index.php?t=getfile&id=31&private=0
First I though that this example will show that RichText is uneven and MS Word is even. Then I noticed that the Ms Word also rendered the distance between "r" and "e" smaller in the "are". Still this seems much less noticable in Ms Word. For example I don't remember seeing anything in Word like the big distance between "n" and "t" in the "important".

[Updated on: Fri, 13 January 2006 00:11]

Report message to a moderator

Re: Topic browser wishes [message #581 is a reply to message #580] Fri, 13 January 2006 08:42 Go to previous messageGo to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
I investigated further the character spacing. It seems that Word and RichText renders the shape of each character differently given the same font & size. This is independent from the position in the line. The first line was rendered by RichText, the second by Word.
index.php?t=getfile&id=32&private=0
Notice for example that RichText renders the letter "c" narrower than the same curve in "d", which gives an uneven look. Also notice the big space after the letter "n". Since RichText renders the letter "n" narrower there are usually this space on either the left or the right side of the "n"-s. I suppose that the difference could be in the rounding the fraction parts of the font sizes. Maybe if the character sizes would be somehow corrected, the spacing issues would not be that noticable.
Re: Topic browser wishes [message #585 is a reply to message #581] Fri, 13 January 2006 09:33 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Well, I am just using regular font rendering of the platform.

In the example you present, size of fonts are not equal (both Word and RichEdit scale them, so setting both to the same point size does not result in the same screen size). RichEdit scaling just results in smaller text (there are more differences than just "c").

However, it is possible that my downscaling algorithm has quirks. You are welcome to comment, the code is easily accessible, see

RichText/ParaPaint.cpp

The actual rescaling is performed around the line 170.
Previous Topic: CodeEditor: scope highlight [BUG]
Next Topic: topic++ browser [BUG][FIXED]
Goto Forum:
  


Current Time: Thu Mar 28 11:25:16 CET 2024

Total time taken to generate the page: 0.01252 seconds