Re: [cssed-devel] Edit menu and HIG

[<mic...@ea...>]

Le 20 mars 2004, =E0 17:43, Iago Rubio a =E9crit :

>> The customize toolbar display a form when you can drag and drop icons
>> from the form to the toolbar. At the beginning you have default=20
>> buttons
>> in the toolbar, then you can add/remove them (all available buttons=20=

>> are
>> in the form). I don't know if we can implement this in cssed, but =
it's
>> very handy.
>
> May be in the future we can make the toolbar configurable. Right now
> thre's not too much to configure on it ;)
I precise for the future: that is the user who decides which icon(s) he=20=

wants in the toolbar, he can remove all of them, just add one and two,=20=

stick with the default, add all, etc. So, from this (his) point of=20
view, all is configurable.

>> View
>>   Show footer panel
>>   Hide footer panel
>>   Show side panel
>>   Hide side panel
>
> Yes it should be ok.
>
>> --------------
>>   Toolbar
>
> It's right now implemented in CVS.
I've just updated from cvs, but this is not implemented, maybe cvs lags=20=

a bit, but zooms are implemented in view.

>> For zoom, etc:
>> Format
>>   Change font (this one taken out from Document menu) or just Fonts
>>   -----------------
>>   Normal
>>   Zoom in
>>   Zoom out
>>
>> As the edit menu is long enough, it is more appropriate to use a=20
>> Format
>> menu.
>
> Not sure about that.
>
> cssed doesn't format tex, itt just format the text's view.
>
> I mean that the "Format" menu can drive the user to think that the =
text
> itself will be saved with format ( as a RTF document, as example ) and
> it's not true in cssed.
>
> It always save plain text, with no format information.
>
> I suposse the "Format" menu deals with text formatting to be stored in=20=

> a
> document, and the user should expect if he/she changes the font format
> and saves the documen,t the next time he/she will open it, it saves =
the
> format selected.
>
> In cssed it's not true, as you're just changing the view's format, not
> the text.
>
> More opinions ??
Yes, you're right. It may be confusing, why not add it to the View=20
menu, at the end. This way, the user cannot be confused.

>
>>>
>>> Bookmarks
>>> 	Add Bookmark
>>> 	Delete Bookmark
>>> 	---------------
>>> 	Next bookmark
>>> 	Previous Bookmark
>>>
>>> Go 				<-  Is this ok ??
>>> 	Previous page
>>> 	Next Page
>>> 	--------------
>>> 	First Page
>>> 	Last Page
>> We should be consistent between menus (Next before Previous), so:
>
> Yes, it's ok.
>
> Will be more carefully with this ;)
The bookmark menu does not exist right now, is not it?

>
>> Go
>>   Next page
>>   Previous page
>>   ----------
>>   First page
>>   Last page
>>
>> I'll guess you mean document here?
>
>
> Yes.
>
> In fact I mean "tab" of the document's notebook.
So why not:
Go
   Next document
   Previous document
   ------
   First document
   Last document

As from the user's point of view, they are documents (the tab of=20
document's notebook is just a programer's thing).

>>> What to add to the second toolbar ?
>>>
>>> Any idea ?
>> View line numbers, View lines wrapped, Enable autocompletion, Fold=20
>> all,
>> Unfold all
>> The above ones could go into first toolbar.
>>
>> Those ones into second toolbar:
>> some main dialogs: border all dialog, font dialog, color dialog,=20
>> margin
>> all dialog, padding all dialog
>> Then: selector wizard, color wizard
>> Then: scan selector, doc info, clean, validate
>
> aaaaargs ! All of them ?
>
> I'm sure we will need more than one extra toolbar ;)
>
> In Gtk the toolbar buttons are 24x24 pixels. So for those entries we
> need a toolbar .... really long :)
What I mean here is take a few dialogs (the most used) and put them in=20=

toolbar.
For example: 5 icons for (border all dialog, font dialog, color dialog,=20=

margin all dialog, padding all dialog), 2 icons for wizards (selector=20
and color), 4 icons for scan selector, doc info, clean, validate.=20
Total: 11 icons.
At the time being, there are 16 icons in the toolbar, so that's less=20
for the second toolbar.

>>>> For the next one, it would be great if we can open a second window
>>>> (i.e. a second instance of cssed), as in bluefish to allow=20
>>>> comparison
>>>> side by side. Just an idea.
>>>
>>> A spliter window ?
>>> To divide a document window in two views of the same document ?
>> No, from my experience, it's difficult for the user to deal with. But=20=

>> a
>> second instance of cssed where you can open another of even the same
>> document. Say you want to use an already existing style sheet to =
build
>> another one. That's the behaviour you obtain in bluefish when =
clicking
>> the new window item in file menu.
>> Then, you can easily copy, drag and drop and so on.
>
> Ok, good idea. It will depend on the ipc stuff, so I must try to put=20=

> the
> ipc queue to work or take it out, after implement this.
Don't forget that ipc queue does not work as is on Mac :-(

Oh I forgot to mention that the POTFILES.in is not accurate, the=20
doc-scanner.c and .h files are missing in it. And, please, don't forget=20=

to wait for the changes in PO files before you release. :-)

Mich=E8le
<http://micmacfr.homeunix.org>