Thread: [cssed-devel] Edit menu and HIG
Brought to you by:
iagorubio
From: Iago R. <iag...@hi...> - 2004-03-12 20:41:19
|
I've changed the edit menu - as posted in previous messages - to match the following layout: Edit Undo Redo ------ Search Search & replace -------- Cut Copy Paste Delete --------- Preferences Must we take out the preferences button from the toolbar ? Something lost ? --=20 Iago Rubio http://www.iagorubio.com =20 GPGkey pgp.rediris.es id 0x909BD4DD fingerprint =3D D18A B950 5F03 BB9A DD89 AA75 FEDF 1978 909B D4DD ********** iago.rubio(AT)hispalinux.es ********** =20 -------------------------------------------------- |
From: <mic...@ea...> - 2004-03-13 01:08:26
Attachments:
PGP.sig
|
Le 13 mars 2004, =E0 2:07, Mich=E8le Garoche a =E9crit : Sorry click on the wrong button when replying. > > Le 12 mars 2004, =E0 21:21, Iago Rubio a =E9crit : > >> I've changed the edit menu - as posted in previous messages - to = match >> the following layout: >> >> Edit >> Undo >> Redo >> ------ >> Search >> Search & replace >> -------- >> Cut >> Copy >> Paste >> Delete >> --------- >> Preferences > > The standard order is: > Edit > Undo > Redo > ------ > Cut > Copy > Paste > Delete > --------- > Search > Search & replace > -------- > Preferences > > It's very important to stick with it, as it can use automatically (I=20= > mean without thinking about where it is placed). > >> Must we take out the preferences button from the toolbar ? > In my opinion, no. It's very handy to have it there, it avoids to go=20= > to the menu. > >> Something lost ? > Well, maybe the delete button in the toolbar. And personally I would=20= > have put the police related toolbar buttons in the menu (not in the=20 > toolbar), and create new buttons for selector scanner, Info on=20 > document, Color wizard, and Selector wizard. Maybe a button too for=20 > display/hide panels (bottom and lateral). And shortcuts in the menu=20 > for show/hide line numbers, wrap/unwrap lines, show/hide=20 > autocompletion, fold/unfold. :-) > > Mich=E8le > <http://micmacfr.homeunix.org> > Mich=E8le <http://micmacfr.homeunix.org> |
From: Iago R. <iag...@hi...> - 2004-03-16 10:44:52
|
On Sat, 2004-03-13 at 02:08, Mich=C3=A8le Garoche wrote: > Le 13 mars 2004, =C3=A0 2:07, Mich=C3=A8le Garoche a =C3=A9crit : > Sorry click on the wrong button when replying. Don't worry I've just done the same with my previous message ;) > > > > Le 12 mars 2004, =C3=A0 21:21, Iago Rubio a =C3=A9crit : > > > >> I've changed the edit menu - as posted in previous messages - to match > >> the following layout: [snip] > > The standard order is: [snip] > > > > It's very important to stick with it, as it can use automatically (I=20 > > mean without thinking about where it is placed). Fixed :) > >> Must we take out the preferences button from the toolbar ? > > In my opinion, no. It's very handy to have it there, it avoids to go=20 > > to the menu. > > > >> Something lost ? > > Well, maybe the delete button in the toolbar. And personally I would=20 > > have put the police related toolbar buttons in the menu (not in the=20 > > toolbar), A little lost about it, can you elaborate it a little please :) ? I'm not sure what you mean with the police related buttons. > and create new buttons for selector scanner, Info on=20 > > document, Color wizard, and Selector wizard.=20 Will start to build some icons for that, but they will be really ugly.=20 I'm not a great graphic artist even while I've worked a lot on plublishing and photography. (If you make a search for "Iago Rubio" in=20 Google I'm sure you will find some info identifying me as "Surfer and photographer from Spain" ;). > Maybe a button too for=20 > > display/hide panels (bottom and lateral). And shortcuts in the menu=20 > > for show/hide line numbers, wrap/unwrap lines, show/hide=20 > > autocompletion, fold/unfold. :-) We must elabotare what buttons will be taken out the toolbar and what we will put into ;) Or, What about a secondary toolbar ? Ah!, Have you got any feature request before the beta release ? Best regards. --=20 Iago Rubio http://www.iagorubio.com =20 GPGkey pgp.rediris.es id 0x909BD4DD fingerprint =3D D18A B950 5F03 BB9A DD89 AA75 FEDF 1978 909B D4DD ********** iago.rubio(AT)hispalinux.es ********** =20 -------------------------------------------------- |
From: <mic...@ea...> - 2004-03-16 23:25:17
Attachments:
PGP.sig
buttons.png
|
Le 16 mars 2004, à 11:43, Iago Rubio a écrit : >>>> Something lost ? >>> Well, maybe the delete button in the toolbar. And personally I would >>> have put the police related toolbar buttons in the menu (not in the >>> toolbar), > > A little lost about it, can you elaborate it a little please :) ? Those ones |
From: Iago R. <iag...@hi...> - 2004-03-18 16:15:09
|
On Wed, 2004-03-17 at 00:25, Mich=C3=A8le Garoche wrote: > Those ones=20 > [ imgs ]Zoom in / Zoom out / Normal size > ______________________________________________________________________ > I use them rarely, so for me they would be better placed in menu, as=20 > articles, normally in Document, or in a new Format menu. Ok. > >> and create new buttons for selector scanner, Info on > >>> document, Color wizard, and Selector wizard. > > > > Will start to build some icons for that, but they will be really ugly. > > > > I'm not a great graphic artist even while I've worked a lot on > > plublishing and photography. (If you make a search for "Iago Rubio" in > > Google I'm sure you will find some info identifying me as "Surfer and > > photographer from Spain" ;). > Wouah, am I talking to a worldwide known surfer? :-) eeeerr .... not a "worldwide known" surfer. But yes a surfer, and member off the Galician's Federation Technicall Staff ;) My brother and friends are still in the surfing business and they run a Surf Camp near my home town http://razsurfcamp.com/index_2003.html where we trained 2002 Junior World Champion Goni Zubizarreta, =20 http://www.aspeurope.com/2003/wqs/ericeira/fotos/day1/ERICEIRAPRO2003Sept25= 2003p/E3zubizareta_JPG.html http://www.masmar.com/noticias/html/17926.html I wrote and developed the surfing courses ;) So if you want some cheap surfing lessons this summer, just send me a mail and take a travel to Spain ;)=20 > >> Maybe a button too for > >>> display/hide panels (bottom and lateral). And shortcuts in the menu > >>> for show/hide line numbers, wrap/unwrap lines, show/hide > >>> autocompletion, fold/unfold. :-) > > > > We must elabotare what buttons will be taken out the toolbar and what=20 > > we > > will put into ;) > > > > Or, What about a secondary toolbar ? > Yes, that was I was thinking about a second toolbar for specialized=20 > tasks: That's a good idea. First we must change the menus to see what can be taken out the toolbar. Reading the HIG I've found the following templates: View Toolbar <- is this ok ? ------------- Zoom in Zoom out Normal Size Bookmarks Add Bookmark Delete Bookmark --------------- Next bookmark Previous Bookmark Go <- Is this ok ?? Previous page Next Page -------------- First Page Last Page //////////////////////// Will be taken out the toolbar: Zoom in (Bigger font size) Zoom out (Smaller font size) Normal Size (Default font size) =09 Any other ?? Ah! ... and, How does it fit with the MacOsX HIG (if any) ? > > Ah!, Have you got any feature request before the beta release ? > None, that I can think of right now. Ok, so once changed the menus and toolbars the first beta will be released :) What to add to the second toolbar ? Any idea ? > For the next one, it would be great if we can open a second window=20 > (i.e. a second instance of cssed), as in bluefish to allow comparison=20 > side by side. Just an idea. A spliter window ? To divide a document window in two views of the same document ? --=20 Iago Rubio http://www.iagorubio.com =20 GPGkey pgp.rediris.es id 0x909BD4DD fingerprint =3D D18A B950 5F03 BB9A DD89 AA75 FEDF 1978 909B D4DD ********** iago.rubio(AT)hispalinux.es ********** =20 -------------------------------------------------- |
From: Alastair P. <ala...@li...> - 2004-03-19 01:42:45
|
On Fri, 2004-03-19 at 05:13, Iago Rubio wrote: > Reading the HIG I've found the following templates: >=20 > View > Toolbar <- is this ok ? As a toggle, yes > ------------- > Zoom in > Zoom out > Normal Size >=20 > Bookmarks > Add Bookmark > Delete Bookmark > --------------- > Next bookmark > Previous Bookmark >=20 > Go <- Is this ok ?? yep > Previous page > Next Page > -------------- > First Page > Last Page >=20 > //////////////////////// >=20 > Will be taken out the toolbar: >=20 > Zoom in (Bigger font size) > Zoom out (Smaller font size) > Normal Size (Default font size) > =09 Looks good for now. Alastair --=20 (o< - A l a s t a i r P o r t e r //\ =20 V_/_ ala...@li... |
From: <mic...@ea...> - 2004-03-19 08:00:14
Attachments:
PGP.sig
|
Le 18 mars 2004, =E0 17:13, Iago Rubio a =E9crit : > On Wed, 2004-03-17 at 00:25, Mich=E8le Garoche wrote: > > So if you want some cheap surfing lessons this summer, just send me a > mail and take a travel to Spain ;) =A1No me digas! > >>>> Maybe a button too for >>>>> display/hide panels (bottom and lateral). And shortcuts in the = menu >>>>> for show/hide line numbers, wrap/unwrap lines, show/hide >>>>> autocompletion, fold/unfold. :-) >>> >>> We must elabotare what buttons will be taken out the toolbar and = what >>> we >>> will put into ;) >>> >>> Or, What about a secondary toolbar ? >> Yes, that was I was thinking about a second toolbar for specialized >> tasks: > > That's a good idea. > > First we must change the menus to see what can be taken out the =20 > toolbar. > > Reading the HIG I've found the following templates: > > View > Toolbar <- is this ok ? > ------------- > Zoom in > Zoom out > Normal Size I don't know for gnome, but Mac is as is: View Anything specific to the application --------------- Show/Hide Toolbar Customize Toolbar In fact the Show toolbar menu item turns into Hide toolbar menu item =20 when the toolbar is shown and vice-versa. The customize toolbar display a form when you can drag and drop icons =20= from the form to the toolbar. At the beginning you have default buttons =20= in the toolbar, then you can add/remove them (all available buttons are =20= in the form). I don't know if we can implement this in cssed, but it's =20= very handy. Apple defines the view menu as <http://developer.apple.com/documentation/UserExperience/Conceptual/=20 OSXHIGuidelines/index.html>: [quote] The View menu provides commands that affect what users see in a window. =20= In the Finder, for example, the View menu contains commands for =20 displaying windows as columns, icons, or lists. Commands for showing, =20= hiding, and customizing a toolbar belong in the View menu. Create a =20 View menu for these commands even if your application doesn=92t need to =20= have other commands in the View menu. Show/Hide Toolbar should appear =20= right above Customize Toolbar. Avoid using the View menu to display utility windows (such as tool =20 palettes); use the Window menu instead. [/quote] So, for example, anything in Panel menu belongs to View menu as it =20 affects what the user views and applies to the whole application, =20 contrary to what is in document menu which is specific to a document =20 (not the whole application). View Show footer panel Hide footer panel Show side panel Hide side panel -------------- Toolbar But better is: View Footer panel (with a case to check) Side panel (with a case to check) -------------- Toolbar (with a case to check) Customize toolbar (if implemented) For zoom, etc: Format Change font (this one taken out from Document menu) or just Fonts ----------------- Normal Zoom in Zoom out Again, definition from Apple: [quote] If your application provides functions for formatting text, you can =20 include a Format menu as a top-level menu or as a submenu of the Edit =20= menu. It may be appropriate to group some items that are in the Format =20= menu into submenus, such as Font, Text, or Style. [/quote] As the edit menu is long enough, it is more appropriate to use a Format =20= menu. > > 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: Go Next page Previous page ---------- First page Last page I'll guess you mean document here? > > //////////////////////// > > Will be taken out the toolbar: > > Zoom in (Bigger font size) > Zoom out (Smaller font size) > Normal Size (Default font size) > =09 > Any other ?? None that I can think of. > > Ah! ... and, How does it fit with the MacOsX HIG (if any) ? Answers above. > > What to add to the second toolbar ? > > Any idea ? View line numbers, View lines wrapped, Enable autocompletion, Fold all, =20= 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, margin =20= all dialog, padding all dialog Then: selector wizard, color wizard Then: scan selector, doc info, clean, validate > >> 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 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 a =20= second instance of cssed where you can open another of even the same =20 document. Say you want to use an already existing style sheet to build =20= another one. That's the behaviour you obtain in bluefish when clicking =20= the new window item in file menu. Then, you can easily copy, drag and drop and so on. And just to make the document menu more pleasant to view: Document View line numbers View line endings View white spaces View lines wrapped --------------- Enable autocompletion Enable folding -------------- Set EOL mode Folding Hightlighting or even better: Document Line numbers (with a case to check) Line endings (idem) White spaces (idem) Wrap lines (idem) --------------- Autocompletion Folding Fold all Unfold all -------------- Set EOL mode Hightlighting And by the way, we need a close document in File menu: File New Open --------- Close Close all (eventually) Save Save as ___________ Quit Wouah, I would not have thought, I wrote so much :-) Mich=E8le <http://micmacfr.homeunix.org> |
From: Iago R. <iag...@hi...> - 2004-03-20 16:44:35
|
On Fri, 2004-03-19 at 09:00, Mich=C3=A8le Garoche wrote: > Le 18 mars 2004, =C3=A0 17:13, Iago Rubio a =C3=A9crit : [snip] > > Reading the HIG I've found the following templates: > > > > View > > Toolbar <- is this ok ? > > ------------- > > Zoom in > > Zoom out > > Normal Size > I don't know for gnome, but Mac is as is: >=20 > View > Anything specific to the application > --------------- > Show/Hide Toolbar > Customize Toolbar >=20 > In fact the Show toolbar menu item turns into Hide toolbar menu item =20 > when the toolbar is shown and vice-versa. Really close to the HIG. > The customize toolbar display a form when you can drag and drop icons =20 > from the form to the toolbar. At the beginning you have default buttons =20 > in the toolbar, then you can add/remove them (all available buttons are =20 > in the form). I don't know if we can implement this in cssed, but it's =20 > very handy. May be in the future we can make the toolbar configurable. Right now thre's not too much to configure on it ;) > Apple defines the view menu as > <http://developer.apple.com/documentation/UserExperience/Conceptual/ > OSXHIGuidelines/index.html>: >=20 [sniped quoted text] >=20 > So, for example, anything in Panel menu belongs to View menu as it =20 > affects what the user views and applies to the whole application, =20 > contrary to what is in document menu which is specific to a document =20 > (not the whole application). >=20 > 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. > But better is: > View > Footer panel (with a case to check) > Side panel (with a case to check) Hmmm ... yes should be. I'll wait a little to implement this, but It will be done in the future. Right now I don't want to bother with the panels state each time the menu is used, but it will be done in the next release. > -------------- > Toolbar (with a case to check) > Customize toolbar (if implemented) > For zoom, etc: > Format > Change font (this one taken out from Document menu) or just Fonts > ----------------- > Normal > Zoom in > Zoom out >=20 > Again, definition from Apple: > [quote] > If your application provides functions for formatting text, you can =20 > include a Format menu as a top-level menu or as a submenu of the Edit =20 > menu. It may be appropriate to group some items that are in the Format =20 > menu into submenus, such as Font, Text, or Style. > [/quote] >=20 > As the edit menu is long enough, it is more appropriate to use a Format =20 > menu. Not sure about that.=20 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 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.=20 In cssed it's not true, as you're just changing the view's format, not the text. More opinions ?? > > > > 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.=20 Will be more carefully with this ;) > Go > Next page > Previous page > ---------- > First page > Last page >=20 > I'll guess you mean document here? Yes. In fact I mean "tab" of the document's notebook. > > //////////////////////// > > > > Will be taken out the toolbar: > > > > Zoom in (Bigger font size) > > Zoom out (Smaller font size) > > Normal Size (Default font size) > > =09 > > Any other ?? > None that I can think of. Ok, will take those out then. > > > > Ah! ... and, How does it fit with the MacOsX HIG (if any) ? > Answers above. Really well explained, thank you :) > > What to add to the second toolbar ? > > > > Any idea ? > View line numbers, View lines wrapped, Enable autocompletion, Fold all, =20 > Unfold all > The above ones could go into first toolbar. >=20 > Those ones into second toolbar: > some main dialogs: border all dialog, font dialog, color dialog, margin =20 > 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 :) > > > >> 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 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 a =20 > second instance of cssed where you can open another of even the same =20 > document. Say you want to use an already existing style sheet to build =20 > another one. That's the behaviour you obtain in bluefish when clicking =20 > 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 the ipc queue to work or take it out, after implement this. > And just to make the document menu more pleasant to view: >=20 > Document > View line numbers > View line endings > View white spaces > View lines wrapped > --------------- > Enable autocompletion > Enable folding > -------------- > Set EOL mode > Folding > Hightlighting >=20 > or even better: >=20 > Document > Line numbers (with a case to check) > Line endings (idem) > White spaces (idem) > Wrap lines (idem) > --------------- > Autocompletion > Folding > Fold all > Unfold all > -------------- > Set EOL mode > Hightlighting It's closer to this right now in CVS. > And by the way, we need a close document in File menu: >=20 > File > New > Open > --------- > Close > Close all (eventually) > Save > Save as > ___________ > Quit In the HIG the close menu is just above the quit menu entry. --------- Close Quit > Wouah, I would not have thought, I wrote so much :-) Yes, thanks. So much writting =3D so much help ;) Best regards --=20 Iago Rubio http://www.iagorubio.com =20 GPGkey pgp.rediris.es id 0x909BD4DD fingerprint =3D D18A B950 5F03 BB9A DD89 AA75 FEDF 1978 909B D4DD ********** iago.rubio(AT)hispalinux.es ********** =20 -------------------------------------------------- |
From: <mic...@ea...> - 2004-03-20 17:46:56
Attachments:
PGP.sig
|
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> |
From: Iago R. <iag...@hi...> - 2004-03-20 18:30:38
|
On Sat, 2004-03-20 at 18:46, Mich=C3=A8le Garoche wrote: > Le 20 mars 2004, =C3=A0 17:43, Iago Rubio a =C3=A9crit : >=20 > >> 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. Ok. Will start to check this to be implemented then. > >> 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. I've just updated the project one hour ago, so almost sure is public cvs is not updated yet. > >> 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. Ok. Will do it then. > > > >>> > >>> 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? No. I'm thinking in it because the cssed bookmarks, are less than bookmarks. Are just session/document oriented markers. Will the user expect to have his bookmarks ready when he reopen the document ? If the name "bookmark" will make the user think those are permanent bookmarks, we must find other name. > > > >> 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 >=20 > As from the user's point of view, they are documents (the tab of=20 > document's notebook is just a programer's thing). Ok. Will be this way then. > >>> 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. border all dialog font dialog color dialog margin all dialog padding all dialog -- selector wizards color wizards -- scan selector doc info clean output -- validate I will add also "validate and dump". The big problem here will be the art work. Will start to bild some icons, but don't expect beautifull ones :( Any other thing in/out the toolbars ? > >>>> 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. [snip] > > > > 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 :-( Don't worry, I've got it in mind. Almost sure the ipc stuff will be aout the release. At least wainting to be more robust, and to know it it's useful. I've no positive reviews about that. > Oh I forgot to mention that the POTFILES.in is not accurate, the=20 > doc-scanner.c and .h files are missing in it. Thanks, will fix it. > And, please, don't forget=20 > to wait for the changes in PO files before you release. :-) Don't worry.=20 Before the release, ee'll get a freeze a one week waiting for the translations to be ready. I've got to change the manual and site also. In the manual, I'm going just to reflect the changes done in the interface, and describe the "doc scanner". Finally, is there a name for the "doc scanner" ? Proposals was: "Doc scanner" ( let it as is ) "Document summary" "Summary" "Digest" and I will add "Declarations browser" <- ugly "Styles browser" <- better, isn't it ? ;) ITHO shorter should be better. --=20 Iago Rubio http://www.iagorubio.com =20 GPGkey pgp.rediris.es id 0x909BD4DD fingerprint =3D D18A B950 5F03 BB9A DD89 AA75 FEDF 1978 909B D4DD ********** iago.rubio(AT)hispalinux.es ********** =20 -------------------------------------------------- |
From: <mic...@ea...> - 2004-03-20 19:10:41
Attachments:
PGP.sig
|
Le 20 mars 2004, =E0 19:29, Iago Rubio a =E9crit : >>> >>>>> >>>>> 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? > > No. I'm thinking in it because the cssed bookmarks, are less than > bookmarks. Are just session/document oriented markers. > > Will the user expect to have his bookmarks ready when he reopen the > document ? > > If the name "bookmark" will make the user think those are permanent > bookmarks, we must find other name. Why not mark? Or another name for the menu: Session Add Bookmark ........ >>>>> What to add to the second toolbar ? >>>>> >>>>> Any idea ? >>>> View line numbers, View lines wrapped, Enable autocompletion, Fold >>>> 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, >>>> 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 >> toolbar. >> For example: 5 icons for (border all dialog, font dialog, color=20 >> dialog, >> margin all dialog, padding all dialog), 2 icons for wizards (selector >> and color), 4 icons for scan selector, doc info, clean, validate. >> Total: 11 icons. >> At the time being, there are 16 icons in the toolbar, so that's less >> for the second toolbar. > > border all dialog > font dialog > color dialog > margin all dialog > padding all dialog > -- > selector wizards > color wizards > -- > scan selector > doc info > clean output > -- > validate > > I will add also "validate and dump". Yes, I've thought about it too. And as you know more about cssed about=20= I do, if you think there are other dialog worth to put in the toolbar,=20= you have 5 icons more (16-11) :-) > > The big problem here will be the art work. Will start to bild some > icons, but don't expect beautifull ones :( They'll be more beautiful than mine, anyway :-) > Any other thing in/out the toolbars ? No idea at the moment. > I've got to change the manual and site also. And don't forget the man page too. > Finally, is there a name for the "doc scanner" ? None that I know of. > Proposals was: > "Doc scanner" ( let it as is ) I fear this one is too close to selector scanner, but well, why not. > "Document summary" > "Summary" > "Digest" As I said, I'm more for Digest. > > and I will add > "Declarations browser" <- ugly > "Styles browser" <- better, isn't it ? ;) What is this? Second one certainly better, though I'm not sure what it=20= is. Mich=E8le <http://micmacfr.homeunix.org> |
From: Iago R. <iag...@hi...> - 2004-03-21 16:33:29
|
On Sat, 2004-03-20 at 20:10, Mich=C3=A8le Garoche wrote: > Le 20 mars 2004, =C3=A0 19:29, Iago Rubio a =C3=A9crit : [snip] > > > > If the name "bookmark" will make the user think those are permanent > > bookmarks, we must find other name. > Why not mark? Yes, much better for me. [snip] > > I will add also "validate and dump". > Yes, I've thought about it too. And as you know more about cssed about=20 > I do, if you think there are other dialog worth to put in the toolbar,=20 > you have 5 icons more (16-11) :-) >=20 > > > > The big problem here will be the art work. Will start to bild some > > icons, but don't expect beautifull ones :( > They'll be more beautiful than mine, anyway :-) No sure about that ;) > > Any other thing in/out the toolbars ? > No idea at the moment. Will start to implement it then. > > I've got to change the manual and site also. > And don't forget the man page too. Ok. > > Finally, is there a name for the "doc scanner" ? > None that I know of. >=20 > > Proposals was: [snip] > As I said, I'm more for Digest. > > > > and I will add > > "Declarations browser" <- ugly > > "Styles browser" <- better, isn't it ? ;) > What is this? Second one certainly better, though I'm not sure what it=20 > is. More names for the "doc scanner" ;) --=20 Iago Rubio http://www.iagorubio.com =20 GPGkey pgp.rediris.es id 0x909BD4DD fingerprint =3D D18A B950 5F03 BB9A DD89 AA75 FEDF 1978 909B D4DD ********** iago.rubio(AT)hispalinux.es ********** =20 -------------------------------------------------- |
From: <mic...@ea...> - 2004-03-21 16:38:38
Attachments:
PGP.sig
|
Le 21 mars 2004, =E0 17:30, Iago Rubio a =E9crit : > On Sat, 2004-03-20 at 20:10, Mich=E8le Garoche wrote: >>> Finally, is there a name for the "doc scanner" ? >> None that I know of. >> >>> Proposals was: > [snip] >> As I said, I'm more for Digest. >>> >>> and I will add >>> "Declarations browser" <- ugly >>> "Styles browser" <- better, isn't it ? ;) >> What is this? Second one certainly better, though I'm not sure what = it >> is. > > More names for the "doc scanner" ;) Forget about them :-) Document structure, maybe? Mich=E8le <http://micmacfr.homeunix.org> |