Thanks for cleaning up these things.
Just for fun I counted the number of menu-items we have at the moment. It's 154 menu-items!

There is more to discuss about main-menu items.

A) I think the menu-item "Project" is more important than the menu-item "File". So it should be the first item. Or put these two into one menu-item.

B) The items "Build","Build All","Abort Build","Quick Compile" should be placed in the "Project" menu-item or the main menu-item "Run" should be renamed.

Regards,

Sam

--- Juha Manninen schrieb am Sa, 5.3.2011:

Von: Juha Manninen
Betreff: [Lazarus] Refactor Menu
An: "Lazarus mailing list"
Datum: Samstag, 5. M?rz, 2011 12:19 Uhr

Hi

I have refactored Lazarus main menu by adding a Refactor menu. :-)

I also added a Source menu.
Eclipse and some other IDEs have done the same thing.

Sometimes it is difficult to decide under which menu a menu item belongs. "Enclose Selection ..." is now under Refactor menu. It could be under Source menu together with "Comment Selection ...", too.

Later the editor local menu will have Source menu, and some checks will be added to disable the entries when they can't be used.

More ideas?

Regards,
Juha

I have refactored Lazarus main menu by adding a Refactor menu. :-) I also added a Source menu. Eclipse and some other IDEs have done the same thing.

Should we start adding Themes to the IDE, i.e. configurable menus? Then it can be made look (and feel) like whatever IDE people are used to.

Sometimes it is difficult to decide under which menu a menu item belongs. "Enclose Selection ..." is now under Refactor menu. It could be under Source menu together with "Comment Selection ...", too.

Sic!

DoDi

I don't think this is a good idea:
1. "File" is the first menu item in basically all applications that exist out there, so this would be a big inconsistency (although - granted - an IDE is a bit of special software)
2. The tasks that are in the "File" menu are very different to the tasks in the "Project" menu, so it would be a very bad idea in my opinion to merge them.

B) The items "Build","Build All","Abort Build","Quick Compile" should be placed in the "Project" menu-item or the main menu-item "Run" should be renamed.

Here I'd prefer the first solution. ;)

Regards,
Sven

Hi

I have refactored Lazarus main menu by adding a Refactor menu. :-)

I also added a Source menu.
Eclipse and some other IDEs have done the same thing.

Sometimes it is difficult to decide under which menu a menu item belongs. "Enclose Selection ..." is now under Refactor menu. It could be under Source menu together with "Comment Selection ...", too.

Later the editor local menu will have Source menu, and some checks will be added to disable the entries when they can't be used.

More ideas?

Regards,
Juha

Honestly, I do not think so.
There is a threshold where "configurable" crosses into "amorphous blob", and I think this is dangerously close ;-)
Lazarus IDE should feel (and look) like Lazarus.

I agree. I also don't think you need to bother with that. It's much more important to add really useful features. Better code libraries (header translations), other refactorings.

Lazarus works well, I know where everything is located, I assume most people that work with it also know it. The ability to change this adds little to no value to the IDE.

Michael.

Samuel Herzog kirjoitti lauantai 05 maaliskuu 2011 11:43:07:

Good point.
I remember it bothered me at first that Project menu was far in the middle, away from File menu. First impressions are often important with GUI because later you get used to any GUI and don't care any more.

File menu being the first one is a GUI convention and moving it would create confusion. The same way the File menu always has "Exit" (or "Quit") although it really has nothing to do with file operations.

I vote for moving Project menu next to File menu, as the second menu. They even have analogous sub-items.
New Unit <--> New Project ...
Open ... <--> Open Project ...
Close ... <--> Close Project ...
Save as ... <--> Save Project as ...

It would be very logical to have them side by side.

B) The items "Build","Build All","Abort Build","Quick Compile" should be placed in the "Project" menu-item or the main menu-item "Run" should be renamed.

Project menu would be very growded.
Besides running a project is different from otherwise managing a project. It is logical to have separate menus for them.

Should it be renamed?
IMO no because menu names should be short. "Run Project" would contain duplicate information.

Should it be moved also?
IMO no because running a project is logically done later. First you create or open a project, using Project menu. Then you edit it, using Edit, Source and Refactor menus. Then you run it, using Run menu.
Chronologically correct order.

Juha

Having a "search" menu: "view search results" should go in there, and not in the "view" menu...
- maybe "jump history" too, not surre?

"procedure list" imho is more a "view", than a "search" think.

"uper/lowercase slection" "tabs to spaces". that applies to any text, not only source, so it should go to the "edit" menu
- imho "sort selection" too, and maybe "break lines in selection" unless it has special source related behaviour...
- "same for "insert from char map";
- probably "insert CVS (well cvs is a hard to place one...), insert general has lots of none source specific...

maybe move "view todo list" to "source", instead of "view" ?

tools "make resource string" should be refactor ?

"jedi code format" could be source...

Maybe a "Debug" menu should be added.
Currently you have some entries in "run" (like add breakpoint); and others in "view/debug window" (which people in the past have already failed to find)

Also "Enviroment" is almost empty. Maybe it could be merged into "tools" (lot's of apps that I know, have the "option" entry either in "tools" or in "edit" menu)

Martin

Problem is as already others said "File" must nowadays be first. Anjd also "edit" comes always second.

Also if you move "project" then what about "package". It makes me wonder if "project" and "package" menu should move next to each other...
but I would leave "project" where it is.

In Lazarus you either work on a project or a package (even so you must have a project open, if you work on a package).
Files are either part of a project or a package (well they can be lose too)

Depending on packages installed, there is

in "view": " ide internals"

in "Tools": "explore ide menu"

IMHO they belong together?

So configurable menus would serve almost all people with a dedicated meaning about which entries should reside where...

DoDi

And some apps change that depending on the OS they run on... example: Firefox. And yes, that is very annoying.

I personally prefer the "Tools" variant.

Regards,
Sven

Juha Manninen wrote

I have refactored Lazarus main menu

...

More ideas?

A further consideration is how to make locating seldom-used functionality accessible easily via the present menu system, without resorting to space-wasting GUI elements such as a Ribbon.

Edit, Search and Run all have 20 or more items, of which several have subitems.

I often find myself searching for functionality I know is there somewhere ... and miss it several times in the long lists.

Is there scope for arranging some items alphabetically, or at least having a fundamental rethink about the order and design of the menus and their subitem lists as they have grown to the present state, so that a menu design can be refined and agreed that will hold for a considerable period up to and beyond a 1.0 release, and be a well-thought-through standard that does not keep changing (familiarity with a stable and logically arranged menu structure saves a lot of frustration), even as new functionality is added.

For instance the Search menu has four separator lines (supposedly grouping related functionality together?) Yet 'Goto line' is at the top of the second section, and 'Goto include directive' is in the middle of the fourth section. And if you add the jumptoimplementation package its menu item gets tagged on at the end; and none of the four separated sections has items that are ordered alphabetically (at least in the English IDE).

I'm not wanting to complain, rather to raise the question if now is not a good time to take stock of the erratic menu growth and changes over the past few years, and as Juha suggests, refactor it constructively.

Howard

Howard Page-Clark wrote

I'm not wanting to complain, rather to raise the question if now is not a good time to take stock of the erratic menu growth and changes over the past few years, and as Juha suggests, refactor it constructively.

The trouble is that the Delphi layout is burned into the minds of many after 15 years. Deviating too far is unconstructive.

many after

15 years. Deviating too far is unconstructive.

Point taken. However, Juha is proposing adding a main menu item which Delphi already has (well, not the XE Starter, but the others) and which Lazarus currently lacks, i. e. improving compatibility.

Also, the subitems in any given menu are often already quite divergent between Delphi and Lazarus. For instance:

D 2010 Edit XE Starter Edit Lazarus Edit
-------------- --------------- ---------------
Undo Undo Undo
Redo Redo Redo
Format Source --------------- ---------------
--------------- Cut Cut
Cut Copy Copy
Copy Paste Paste
Paste Delete ---------------
Delete Select All Indent selection Select All --------------- Unindent selection --------------- Align to Grid Enclose selection... Align to Grid Bring to Front Comment selection Bring to Front Send to Back Uncomment selection Send to Back Toggle comment
Align... Insert $IFDEF
Size... Sort selection
Scale... ---------------
Tab Order... Uppercase selection Create Order... Lowercase selection Flip Children > Tabs to spaces in selection Lock Controls Break lines in selection ---------------
Select >
---------------
Insert from Character Map
Insert text >
---------------
Complete code
Extract procedure

After 'Paste' there is no correspondence that is in any way helpful if you've memorised Delphi's menu order. So surely if reordering items (or moving them to another menu, or renaming them) can be shown to be a widely welcomed improvement, I see no reason to refuse consideration simply because Delphi's menu differs. It's never been identical, and with the superiority of quite a bit of Lazarus' functionality, I think a well-considered Lazarus menu structure that takes account of logicality, cross-platform considerations and internationalisation issues could show Delphi the way, since Lazarus is not constrained by a Windows-only history. Though I agree that gratuitous departure from the Delphi pattern for its own sake is pointless.

H

Op 2011-03-05 16:03, Martin het geskryf:

"procedure list" imho is more a "view", than a "search" think.

No, it's a search. I use "procedure list" to find a specific procedure or method in the current unit. Alternatively, I could have used the standard "find", but "procedure list" is faster... Bottom line, it's a search function.

Then again, restructuring the menus wouldn't make much difference to me, because I use keyboard shortcuts for all my most used IDE functionality items anyway. :)

Regards,
- Graeme -

Op 2011-03-05 18:26, Howard Page-Clark het geskryf:

I often find myself searching for functionality I know is there somewhere ... and miss it several times in the long lists.

I find this problem too, especially when new functionality is added to the IDE. I think the IDE needs a menu item that opens a dialog that searches all registered menu items - very similar [if not identical] to the way the "Editor - Key mapping" dialog works.

Thus you can type the name of the functionality, and the available menu items in that dialog get filter to leave only the items that match the filter.

I think the Delphi XE IDE has something like that too. Pretty clever feature.

Regards,
- Graeme -

Op 2011-03-05 15:02, Juha Manninen het geskryf:

confusion. The same way the File menu always has "Exit" (or "Quit") although it really has nothing to do with file operations.

Some Windows & Linux applications (and all MacOSX applications) have a "application" menu item - which is the first item in the menu bar, and has the name of the application as the title (eg: "Lazarus"). In there it contains things like "Quit", "Preferences" etc... which all applies to the application - this actually make a lot more sense than putting such items in a "File" menu.

Granted, I'm not suggesting removing the "File" menu, as it has many items which indeed relate to a file operation.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Some Windows & Linux applications (and all MacOSX applications) have a "application" menu item - which is the first item in the menu bar, and has the name of the application as the title (eg: "Lazarus").

Out of curiosity: can you name some of these "Some Windows & Linux applications"?

Regards,
Sven

Howard Page-Clark kirjoitti maanantai 07 maaliskuu 2011 00:29:39:

I didn't only propose it, I actually implemented "Source" and "Refactor" menus in Lazarus trunk.
The "Edit" menu now looks very different from your list.

I will return to menu changes little later. However I try to be careful not to implement every idea that comes to my or someone else's head. The menu structure is subjective, a matter of opinion, and will never be perfect. I already know there will be opposite opinions about any change proposed.

Regards,
Juha

Martin kirjoitti lauantai 05 maaliskuu 2011 16:03:06:

"jedi code format" could be source...

Right. These Tool menu items could go there also:

Quick Syntax check
Guess unclosed block
Guess misplaced IFDEF/ENDIF

I will look at your other ideas closely later.
Moving "Project" menu was maybe a bad idea.

Juha

Sven Barth wrote

Out of curiosity: can you name some of these "Some Windows & Linux applications"?

Sure... gFTP under Linux, I guess you can add Opera and Chrome to the list because they use the application name or logo to access there menu. Then I guess you can add any of the new Microsoft applications which uses that tabbed-style toolbar thingy. They also have an "application logo" in the top/left which pulls down the menu when you click it etc.. There was a few more apps that use purely menus like gFTP, but I think you get the idea. The mac-style "application name" as first menu entry is slowly catching on in other platforms too. I'm seeing it more and more - even our custom written company applications (for Linux and Windows) are using it now, and our clients think it's quite logical - more so than a File menu when you aren't even working with files. :)

do you mean that it is more logical than using a menu labeled "START" to find the "SHUTDOWN" or "REBOOT" option??? :lol:

Op 2011-03-08 04:46, waldo kitty het geskryf:

do you mean that it is more logical than using a menu labeled "START" to find the "SHUTDOWN" or "REBOOT" option??? :lol:

:-) And then some people wonder why I DON'T use Windows! Under Linux most distros call that the Application or Logo, Distro Logo button. MacOSX calls it the Apple menu. In my Window Manager, I don't have such a button, I simply need to click the desktop background to get a menu. So, as usual, it's just Microsoft that got it wrong. :)

Regards,
- Graeme -

Please, Please. Think about this thread from a absolute beginners point of view.

He starts the IDE the first time and of course he wants to see some action. Probably he will choose "Run" and see an empty form. Next step. He will look for some examples to open and run. Of course he starts looking into "File" menu but not find it because it's somewhere in the middle in the Menu "Project".

I have also added a feature request in bug-tracker to fill some examples into the "Recent projects" list when installing lazarus.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110308/ca6016ed/attachment.html>

So, as usual, it's just Microsoft that got it wrong. :)

You remember "Press CTRL-ALT-DEL to log in"?

A nightmare for old MS-DOS users :-(

DoDi

Touching in *Think about this thread from a absolute beginners point of view. *Well, a strange thing (as i think) is try to run [F9] a unsaved project (i think it happens on build to but i didn?t test), compiler raises a Linking Fail error, but if you saves the project in some folder than compiler buids the project nicely.

I think lazarus should temporary saves a unsaved project to a temp path to compile, beginner users won't get suprised with.... ________________________________
William de Oliveira Ferreira
Bacharel em Sistemas de Informa??o

2011/3/8 Samuel Herzog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110309/f0a22c49/attachment.html>

The IDE saves the project to a temporary directory and compiles it there.
Please report the bug together with your fpc, lazarus, OS version and how you installed Lazarus (svn, snapshot, ...)

Mattias

Hi

I moved items between Edit, Source, Refactor and Tools menus. Now also some packages register their menu items under Source, View and Environment menus instead of Tools menu.
I am quite happy with most item locations.
However "Enviroment" menu needs some attention as Martin noted.

Now there is a huge Options dialog where even the list of setting page names (in a treeview) doesn't fit into the default sized window but must be scrolled. Then there are 2 small setting dialogs:
"Code templates" and "Codetools defines editor".
A question arises, why are they not integrated into the huge Options dialog like everything else.

One idea: "Options" could be moved to Tools->Options or Edit->Preferences. The other settings could go there, too. Scan FPC directory would go to Tools. Enviroment menu would go away.
On the other hand some packages can register their settings into a menu. It makes sense to have one dedicated menu for settings. I would like to see the big Options dialog splitted to many, and have them under the menu. The menu could be renamed to "Settings" or even "Application" if it feels better.

---

There were more ideas from Martin and others which I didn't implement:

- IMO "search results" and "debug window" fit well under View menu because you can open them also when not searching or debugging. Besides the windows are typically opened automatically when searching / debugging.

- Having a Debug menu would practically replace the Run menu because most items deal with debugging or both debugging and running. It could be a good idea to move the upper "Build" section (4 items) to Project menu (like Delphi has it), and rename "Run" to "Debug". On the other hand, I don't see any big problems with the current "Run" menu.

- The character insertion items should all be collected into one place. IMO the source menu is the best fit.

More ideas are welcome.

Juha

Please leave the options dialog as it is. It works well.

One place for all settings is GOOD !

Often you don't know where exactly a setting is, but now you can find it easily. If you split the dialog it into many, it means closing the dialog, going to a new menu point, opening a dialog. That is simply wasting time. And for what ? Because you must scroll in a tree ? The alternative is worse and will be lots slower.

Do not change things for the sake of changing.
These thing must have a reason, they must improve the IDE.

Michael.

Juha Manninen wrote

Now there is a huge Options dialog where even the list of setting page names (in a treeview) doesn't fit into the default sized window but must be scrolled.

..

I would like to see the big Options dialog splitted to many, and have them under the menu. The menu could be renamed to "Settings" or even "Application" if it feels better.

Actually, they "just" got moved together... 0.9.26 had them separated.

Please keep in mind, that them being together is important for future plans: like a search field in the option dialog, that searches for the key-word in *all* options.

Martin

Michael Van Canneyt kirjoitti keskiviikko 09 maaliskuu 2011 23:37:49:

Sounds reasonable.
Now some exact setting is not very easy to find but the future filter/search feature will help a lot.

Still, some settings are split into small dialogs, namely "Code templates" and "Codetools defines editor" + settings registered by packages. They don't match with the design goal of centralized settings. Maybe the plan is to unite them, I don't know.

If the menu had only 2 items (Options and Scan FPC dir), it should be deleted and the items moved elsewhere.
Now it has more items and potentially still more coming from packages. I guess it is needed.

Do not change things for the sake of changing. These thing must have a reason, they must improve the IDE.

I try to be careful with that.
I feel the changes so far made the menus more logical and intuitive.

Juha

Juha Manninen wrote

One idea: "Options" could be moved to Tools->Options or Edit->Preferences. The other settings could go there, too. Scan FPC directory would go to Tools. Enviroment menu would go away.

If you move the "Options", then I'd vote for "Tools->Options", because that sounds more reasonable to look for configuration than the "Edit" menu... (just my opinion)

On the other hand some packages can register their settings into a menu. It makes sense to have one dedicated menu for settings.

Maybe the packages should be modified to register their settings in the "Options" dialog then (the JCF does that afaik).

To prevent something like this maybe a "best practices" guide for IDE packages should be made (or is there already one?), which could contain something like "register settings in the Options dialog instead of creating a custom menu item"

Regards,
Sven

?
?

Sven Barth hat am 10. M?rz 2011 um 10:52
geschrieben:

Only very few packages use this yet (afaik jcf and educationlaz), because the interface for this ability is new and not very stable yet. It was introduced in 0.9.28 and changed in 0.9.30. I am not sure it is stable yet. ?

?

To prevent something like this maybe a "best practices" guide for IDE packages should be made (or is there already one?), which could contain something like "register settings in the Options dialog instead of creating a custom menu item"

AFAIK it is not documented yet.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110310/b851ac9e/attachment.html>

I think* tools --> options *means configuration for lazarus tools and not for lazarus environment...
________________________________
William de Oliveira Ferreira
Bacharel em Sistemas de Informa??o

2011/3/10 Mattias Gaertner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110310/3db32c11/attachment.html>

submitted, i only forgot to say how i've installed it ________________________________
William de Oliveira Ferreira
Bacharel em Sistemas de Informa??o

2011/3/9 Mattias Gaertner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110310/ad789db3/attachment.html>

William Oliveira Ferreira kirjoitti torstai 10 maaliskuu 2011 13:16:25:

I think* tools --> options *means configuration for lazarus tools and not for lazarus environment...

I am not moving the Options menu item now. It is controversial as we notice. Besides the Environment menu still has other items. If the other setting dialogs are integrated into Options dialog, then Environment menu will have 2 items left which can be moved and Environment menu removed.

Juha

William Oliveira Ferreira kirjoitti torstai 10 maaliskuu 2011 14:43:13:

submitted, i only forgot to say how i've installed it

You really should test with a more recent Lazarus, either 0.9.30 or 0.9.31. 0.9.28.2 is over a year old.

Juha

I use only "final" releases, that's available for common users... ________________________________
William de Oliveira Ferreira
Bacharel em Sistemas de Informa??o

2011/3/10 Juha Manninen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110310/a43ece92/attachment.html>

William Oliveira Ferreira wrote

I use only "final" releases, that's available for common users...

a reasonable decision... for working with it.

However you can always install another version in parallel (just ensure you start it with --primary-config-path=C:\someplace to keep it's own conf) That allows you to test snapshots.

btw: your issue was known soon after release:
http://wiki.lazarus.freepascal.org/Lazarus_0.9.28.2_release_notes and back then I believe there may have even been a snapshot from a 0.9.28.2 fixes branch (but I can't be 100% sure of it)

Anyway, you can wait a bit 0.9.30 is soon to be released.

or download the current 0.9.29 fixes snapshot => that should be 99.9% identical with the will be release.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110310/aa2ca89a/attachment.html>

But it's that version i iuse...
The bug is marked as fixed but it still heappens to me...

btw: your issue was known soon after release:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110310/fccca59f/attachment.html>

William Oliveira Ferreira kirjoitti perjantai 11 maaliskuu 2011 03:59:12:

But it's that version i iuse... The bug is marked as fixed but it still heappens to me...

That is why you should use a more recent version.
The bug was fixed well over a year ago!

Best choice is a 0.9.29 snapshot which is almost the same as 0.9.30 will be. The development trunk version is also very usable. The current versions of Lazarus are much more stable than 0.9.28.2. There is really no need to use the older version if you have problems with it.

Also, reporting bugs is good but they are most helpful if you test them against the development version.

Juha