FWIW, I often use "Quick search" (Ctrl+E) for code navigation, since I remember some arbitrary piece of code to jump to, not necessarily a function name.

I think that while Lazarus IDE has many great features, they are not well organized. Various Lazarus developers added convenience features with a separate user interfaces, so the features are dispersed all over UI and hard to discover.

IMHO the good way forward is to consolidate some feature groups into a common UI, thus giving greater exposure to all included features.

I realize that may be a controversial topic, as developers might "defend" their pet features from consolidation, stating that consolidated UI is less convenient than specialized ones, but I think there should be a balance of uniformity versus specialization, and right now this balance is tipped far on the specialization side.

If there is a general agreement, I can prepare detailed proposal for consolidation,
but as a quick sketch:
1) "Find procedure" should be merged into "Code explorer"
2) "Find in files", "Messages" and "Code observer" should be merged together, with interface most resembling "Find in files"
3) "Unit list" (Ctrl+F12) should be merged into "Project Inspector"
4) "Find unused units" should be merged into "Unit dependencies"

... and so on

Alexander Klenin wrote

If there is a general agreement, I can prepare detailed proposal for consolidation, but as a quick sketch: 1) "Find procedure" should be merged into "Code explorer"

What is "Find procedure"? But since I dont use it I am not against :)

2) "Find in files", "Messages" and "Code observer" should be merged together, with interface most resembling "Find in files"

"Code observer" shows IDE hints which IDE builds on the fly. "Messages" appeared only after some actions mostly with compiler. "Find in files" is also not a process which IDE do without demand. It is difficult to imagine how you want to combine them together.

If you want to just add tabs to the Messages window then I am not againts. But maybe just better to dock Code explorer window into source editor? Then you will see "Code observer" all the time.

3) "Unit list" (Ctrl+F12) should be merged into "Project Inspector"

How? If you want to remove Ctrl+F12 then I'm againts this change. We all used to it. If you want to extend "Project Inspector" then it is ok.

4) "Find unused units" should be merged into "Unit dependencies"

It is a good idea.

Generally speaking consolidation idea is not bad. But each case should be discussed. Some cases can be coverted by docking (for example code explorer + source editor), some by merging dialogs (for example compiler options + project options).

Please create a wiki page. After few revisions it can become a part of roadmap.

Best regards,
Paul Ishenin.

Excellent idea ! I think it should be true for any window to dock or put on top. Lastly I debuged asm code and had to click on Windows menu to bring registers window back on top to see how EDX changed. Very annoying.In fact under win32 it could be a few lines of code to make window stay on top but somehow it didn't work (Form.Handle is not correct WinApi HWND or something is messed with window parameters in runtime by LCL).Maybe docking will be better.

Best regards
Boguslaw Brandys

Alexander Klenin wrote

FWIW, I often use "Quick search" (Ctrl+E) for code navigation,

How does "quick search" work? I highlighted an identifier I want to seach for, pressed Ctrl+E. It showed "seaching" in the editor status bar, but nothing further. Sometimes it highlights a whole bunch of stuff like the letter "e". I'm a bit lost. :-(

I think that while Lazarus IDE has many great features, they are not well

I just think many of those feature are silently added with nobody knowing. Hence the reason I started the following wiki page.... to advertise those cool features and visually see what they do.

http://wiki.lazarus.freepascal.org/New_IDE_features_since

a common UI, thus giving greater exposure to all included features.

The wiki pages is trying to give greater exposure as well - visually with animation.

1) "Find procedure" should be merged into "Code explorer"

I don't know "Find procedure" where is that? I used the filter in "key mappings" and found "find procedure definition" and "find procedure method" using the age old Ctrl+shift+Up/Down. I would have expected everybody to know the latter key mapping - it's what makes the Lazarus and Delphi IDE such a pleasure compared to other programming editors.

2) "Find in files", "Messages" and "Code observer" should be merged together, with interface most resembling "Find in files"

I can't see how these can be combined. They are totally different features. Maybe the result windows could be docked though.

3) "Unit list" (Ctrl+F12) should be merged into "Project Inspector"

I guess, but I simply have the "project Inspector" window always open. So I simply click a unit to open it.

As Paul suggested. I think docking is the key here... it will make many feature or windows more manageable.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Highlight (as in block-selection) and then search for it => use ctrl-f

Quick search (or incremental search) (ctrl-e) means you start the search with an empty search-term, then as you type the editor searches for whatever fragment you typed
ctrtl-e => status-bar displays searching
b => status bar displays "b" / editor goes to the next "b" (b is highlighted, all other occurrences are highlighted in yellow) e => status bar shows "be" / editor goes to next "be" f => "bef" => ....
backspace => "be" editor returns to "be"
g, i, n => "begin"

- while in quicksearch, pressing F3 or ctrl-e again => jump to the next search result of the same term
- start quick search with ctrl-e, ctrl-e => resume with last search term

Martin

It is like Firefox built-in search: start typing, and it moves to the next occurrence of the typed string.

The wiki pages is trying to give greater exposure as well - visually with animation.

Yes, documentation is good.
But it is well-known fact that users do not read documentation ;-)

Sorry, I meant "Procedure List".

Although different in implementation, they are very similar in output: they all display a hierarchial list of strings, each string tied to a code location.
Look how it is done in Visual Studio 2005 and later.

> 3) "Unit list" (Ctrl+F12) should be merged into "Project Inspector" I guess, but I simply have the "project Inspector" window always open. So I simply click a unit to open it.

Yes, just add keyboard shortcut and searching feature from unit list to project inspector, then "unit list" becames a strict subset of it and can be safely removed.

As Paul suggested. I think docking is the key here... it will make many feature or windows more manageable.

I very much agree that docking is important. However, even with docking one can manage only a limited number of open windows.

Ok by me. (I never used it :) ) It's partly there anyway.

2) "Find in files", "Messages" and "Code observer" should be merged together, with interface most resembling "Find in files"

IMHO, this (point 2) would be even more a specialization. Also I can't see how those 3 , for that lets wait for docking.

3) "Unit list" (Ctrl+F12) should be merged into "Project Inspector" 4) "Find unused units" should be merged into "Unit dependencies"

I was thinking "Unit dependencies" could also be merged to "Project Inspector"....

... and so on

what about:
- keybard layouts?
- Menu layouts?

Best Regards
Martin

Zitat von Graeme Geldenhuys :

Ctrl+e is in incremental find. It searches while you type.

see here
http://wiki.lazarus.freepascal.org/Lazarus_IDE_Tools#Incremental_Search

> I think that while Lazarus IDE has many great features, they are not well I just think many of those feature are silently added with nobody knowing.

Well, they were added experimentally, then matured gradually over time.

:)

It's called 'procedure list' and its default key is Alt-G, which does not work on all widgetsets.

All floating windows should be dockable. We have already a docking manager. The missing part is to finish the save/restore of the layout.

Mattias

Martin Friebe wrote

Highlight (as in block-selection) and then search for it => use ctrl-f

Yeah, that's what I normally use...

Quick search (or incremental search) (ctrl-e) means you start the search with an empty search-term, then as you type the editor searches for whatever fragment you typed

Ah, ok I get it now. Maybe "Quick Search" is not the best name for that feature. "Incremental Search" explains it much better. Just a thought.

Thanks for explain its function Martin. ;)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Zitat von Martin Friebe :

Please add this to the wiki.

Mattias

Alexander Klenin wrote

Yes, documentation is good. But it is well-known fact that users do not read documentation ;-)

Exactly why I decided on using animated gifs. User only needs to view them and not read content to get the idea of a feature. :)

Sorry, I meant "Procedure List".

Before merging with "code explorer" I'd like this to be discussed first! Like I mentioned before, "procedure list" is an integral part of my coding. I use it 1000's of times per day to navigate code - QUICKLY. :)

Look how it is done in Visual Studio 2005 and later.

I don't do Windows, so is there a screenshort explain this? Like somebody suggested - maybe starting a wiki to describe what the plans are and maybe include screenshots (mock-up or real) to show an idea of final result.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Martin Friebe wrote

> 1) "Find procedure" should be merged into "Code explorer" Ok by me. (I never used it :) ) ?It's partly there anyway.

Lets discuss it first - I use "procedure list" a *lot*. And at the moment it's behaviour is different to code explorer.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/5/6 Mattias G?rtner :

It's called 'procedure list' and its default key is Alt-G, which does not work on all widgetsets.

Do you mean the shortcut doesn't work or the actual "procedure List" dialog doesn't work on all widgetsets?

Since I switched from GTK1 to GTK2, "procedure list" doesn't work as well. I think it's due to a bug in GTK2 listview, but I haven't investigated further.

To reproduce:
* Alt-G (or whatever your shortcut is - mine is always different) to open Procedure List.
* Start typing partial method name.
* Now press Down Arrow. This should put focus in first item in listview, but it doesn't. :-(
This used to work under GTK1.

Other differences between Procedure List and Code Explorer.
* Procedure List jumps to Implementation section. Code Explorer to Interface section.
* Procedure list can filter by Class, non-class or All methods. I don't think Code Explorer can.
* Procedure List can filter by "method starting with text" or "method containing text".
Not sure what Code Explorer does.
* Procedure List, when launched puts focus where it must be - in the filter edit box.
Code Explorer - I have no idea where the focus is, I think the treeview (filter box
might be a better idea).
* In procedure list, when you press Enter to jump to a method, Procedure List closes
and gets out of the way. Code Explorer hangs around taking up screen space.

So yes, there are plenty to discuss before any merge is to be considered. Please.

All floating windows should be dockable. We have already a docking

Excellent! Can we enable docking already in Lazarus - even though it isn't saved and restored between sessions?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/5/6 Mattias G?rtner :

I started to look at fixing save/restore once, but dropped it since docking is being rewritten by Hans-Peter Diettrich

Of course, no need to rush.
But notice how even many people on this list do not know about procedure list -- merging with code explorer should help that.

Graeme Geldenhuys wrote

Other differences between Procedure List and Code Explorer. ?* Procedure List jumps to Implementation section. Code Explorer to Interface section.

I would prefer to always jump to implementation, but it can be made an option.

Yes, filtering should be added to code explorer.

?* Procedure List, when launched puts focus where it must be - in the filter edit box. Code Explorer - I have no idea where the focus is, I think the treeview (filter box might be a better idea).

Yes, after the merge Alt+G shortcut should put focus in similar field in code explorer.

?* In procedure list, when you press Enter to jump to a method, Procedure List closes ? ?and gets out of the way. Code Explorer hangs around taking up screen space.

Well, I have Code Explorer always open anyway, but I guess it can be made an option too.

So yes, there are plenty to discuss before any merge is to be considered. Please.

Do not worry, the goal it to make everything better ;-)

Zitat von Graeme Geldenhuys :

Alt-G does not work. With other short cuts it works.

Yes. And this is needed.
Maybe jumping to implementation can be added with a modifier key. And an option can be added to toggle With/Without modifier and Interface/Implementation.

* Procedure list can filter by Class, non-class or All methods. I don't think Code Explorer can.

Very easy to implement. Make a proposal for the gui.

* Procedure List can filter by "method starting with text" or "method containing text". Not sure what Code Explorer does.

containing

* Procedure List, when launched puts focus where it must be - in the filter edit box. Code Explorer - I have no idea where the focus is, I think the treeview (filter box might be a better idea).

Patch is welcome.

* In procedure list, when you press Enter to jump to a method, Procedure List closes and gets out of the way. Code Explorer hangs around taking up screen space.

code explorer is a floating window, normally visible all the time and placed left or right of the source editor.

So yes, there are plenty to discuss before any merge is to be considered. Please.

> All floating windows should be dockable. We have already a docking Excellent! Can we enable docking already in Lazarus - even though it isn't saved and restored between sessions?

1. afaik drag&drop docking does not work on gtk. Only docking via menu item.
2. docking without restore is as useful as a lazarus without projects. Maybe some predefined sets can be added until someone finishes the restore of one of the docking managers.

Mattias

Yup, I prefer that too.

The problem with "Code Explorer" and "FPDoc Editor" type windows is that they use processing power as you navigate or switch units. Hence the reason I don't like keeping them open. When I need them I open them, but once done, I close them again. I also prefer to have my source editor area as large as possible. "Procedure List" follows the same rules. Only there when needed and doesn't use extra processing power if not used.

Not everybody has fast computers - developers in our company are probably last on the list of having their systems upgraded. Our receptionist has a faster computer that what I have - and she only types letters and sends emails. :-(

Do not worry, the goal it to make everything better ;-)

:)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Erm...

Ok, maybe I know more about UI than others, maybe I know less.

But IMHO, *everything* should be accessible via the menu. So if you don\'t know a shortcut, you can click
Menu - IDE Tools - Procedure list
Menu - IDE Tools - Anchor Viewer
Menu - IDE Tools - Identifier Completion (ctrl-space) (says -you need have typed half of an identifier for this tool to work- if you can not complete)
Menu - IDE Tools - Code Completion (ctrl-shift-c)

etc.

So as soon as a developer adds a new feature... it should be added to the menu too. Or at the very least a popup menu.

This way there cab no features that a user does not know about. They can now see it\'s there. So go play with it. Except if they don\'t read the menus.

Regards,
-Reenen

Does it conflict with OS or Desktop Manager? For example: Ctrl+Alt+[F1-F12] under Ubuntu is grabbed by X11 and switches virtual consoles. Maybe a different default shortcut could be chosen. I have my shortcuts as follows:

* Alt+G -> Goto line number...
* Ctrl+G -> Procedure List
* Ctrl+Shift+G -> Generate GUID in editor

Alt key behaviour is weird under GTK2 with Programmer Dvorak layout. Though I am not use if it affects Qwerty layout as well. For example I click "grab" and type Ctrl+Alt+C and only Ctrl+C is grabbed. Yet if I press Ctrl+Alt+G it works?? Weird. :-(

BTW: How do I clear a keyboard shortcut? Can't a simple "clear" button be added?

> ? * Procedure list can filter by Class, non-class or All methods. I > don't think Code Explorer can. Very easy to implement. Make a proposal for the gui.

Will do.

OK. Also filtering the treeview as you type might be better that multi-selecting all matches. What's the point of having multiple methods selected? The edit box is called "filter" not "auto select". Just a though. ;-)

No problem, but it doesn't make sense until the treeview is actually filtered, as my previous point explains. At the moment I can type a partial method and see methods being selected (unless they are select off screen which also happens), but I can't press enter and jump to that method. I need to tab and scroll down (which defeat the "fiter" edit box) or move my hand off the keyboard and to the mouse, so I can double click the highlighted item. The "filter" edit box in Code Explore just doesn't make sense - as it is now.

Maybe some predefined sets can be added until someone finishes the restore of one of the docking managers.

That should make a few developers happy. :)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reenen Laurie wrote

?Menu - IDE Tools - Procedure list ?Menu - IDE Tools - Anchor Viewer

Both of these are already under the "View" menu.

?Menu - IDE Tools - Identifier Completion (ctrl-space) (says -you need have typed half of an identifier for this tool to work- if you can not complete) ?Menu - IDE Tools - Code Completion (ctrl-shift-c)

It makes no sense in having menu items for these from the main Lazarus window. They are used in the editor *while* you type. Otherwise I type partial text. Move my hand off the keyboard onto the mouse and select the menu items. Then move my hand back onto the keyboard to continue typing. A simple shortcut is all that is needed.

If you don't know the shortcut, use the Key Mappings screen and filter the items by typing in a description.
"Environment > Options > Editor > Key Mappings". By typing in "comple" will give you all the items your require. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Quick Search would be something that Lazarus seems to still be missing: search the identifier under the caret.
Like in Visual Studio: Ctrl+F3 to search forwared and Ctrl+Shift+F3 backwards. Or with Experts: Ctrl+Alt+Down and Ctrl+Alt+Up.
I've always intended to implement this, but...

Best regards,
Fl?vio

Zitat von Fl?vio Etrusco :

.. but it was already there:

http://wiki.lazarus.freepascal.org/Lazarus_IDE_Tools#Find_next_.2F_previous_word_occurrence

Mattias

2009/5/6 Fl?vio Etrusco :

Quick Search would be something that Lazarus seems to still be missing: search the identifier under the caret.

Ctrl+F automatically takes what's under the caret and inserts it as the search text. I think this is configurable somewhere in Lazarus IDE. Then press Enter to find first item. F3 to find next items.

Or with Experts: Ctrl+Alt+Down and Ctrl+Alt+Up. I've always intended to implement this, but...

Me too! :) I used to use that a lot in Delphi 7 + GExperts.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

window will know what to do (show related place in source code) when an entry is clicked.

Anyway, for that lets wait for docking.

Some notes on docking:

The "Messages" and "Search Results" can be docked to the IDE main window, eventually by default.

The docking of forms is unsupported on many platforms, due to the different management of controls (widgetset) and windows (window manager). So all dockable windows should contain one single component for their entire content. (or the forms should float as clients of a floating form). This requirement lead me to another suggestion:

When one or more forms are docked into another window, their UI (menus, toolbars...) could be added to the dock host form's UI. Just an idea...

what about: - keybard layouts? - Menu layouts?

Some visual design for toolbars (and menus) would be nice, as in the Delphi IDE window (configure by drag&drop from the list of available options to a toolbar).

DoDi

2009/5/6 Mattias G?rtner :

Yet again you impress me with the Lazarus IDE features. Thanks Mattias, I assigned by custom Ctrl+Alt+[up/down] to them.

BTW:
I had a recent discussion on CodeGear non-technical newsgroup about Lazarus's Key Mapping screen. Can you believe it that Delphi IDE (even D2009) still doesn't allow you to set key mappings to all IDE actions. Yes you can use add-ons like Castalia or GExports, but *not* out-of-the-box as Lazarus does. :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Paul Ishenin wrote

Please create a wiki page. After few revisions it can become a part of roadmap.

http://wiki.freepascal.org/IDE_UI_Consolidation

Users who don't want to waste time with reading, also won't want to waste time with videos - in detail when they found out after the first video that the demonstrated feature does not fit their needs.

IMO the wiki should be structured in a strict way, e.g. all "search" features should be summarized together. Two subsections "search what/where" and "search how". Quick/incremental search obviously should go into the "search how" category.

Could it be extended by a list of favorites? I.e. a configurable list of currently used/related/important procedures - similar to bookmarks, but more expressive with only the names of procedures (or types...).

DoDi

Zitat von Graeme Geldenhuys :

Ctrl+Alt+Up/Down is often used in linux for desktop switching.

Mattias

On 5/6/09, Graeme Geldenhuys wrote:

Reenen Laurie wrote

> ?Menu - IDE Tools - Procedure list > ?Menu - IDE Tools - Anchor Viewer Both of these are already under the \"View\" menu.

Procedure list is not on my view menu... Maybe in a newer revision. :-/

If you don\'t know the shortcut, use the Key Mappings screen and filter the items by typing in a description.

The point is that if you don\'t know about the functionality, you won\'t smell it. The keyboard shortcut should be displayed next to the menu item so that you learn it as you do it. Admittedly the stuff that gets done as you type should rather go on a context-popup menu. And... actually most is already on the pop-up under refactoring.

Everyday you learn more! But had it not been for this thread I would not have known.

What does Enclose Selection do?

2009/5/6 Mattias G?rtner :

I know, and that's one of the first things I disable in Gnome desktop. :)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reenen Laurie wrote

What does Enclose Selection do?

Click it - I dare you! ;-)

It allows you to choose with what you want to wrap the currently selected code.

eg: try..finaly, try..except, repeat..until, while..do, {....} etc..

I learnt that one today as well - and it will save me lots of time as well. I just need to figure out what would be a good keyboard shortcut for it. I have so many custom ones already.

My todo list already contains a "create Lazarus add-on to all printing keyboard shorcuts as reference cards". I just don't know when I will get around to implementing it.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

It will be implemented soon. Currently it's abused for an dump of the internal tree structure (debug feature).

A redesign of the dockable IDE windows may be required, so that drag&dock will work on all platforms.

DoDi

The problem with "Code Explorer" and "FPDoc Editor" type windows is that they use processing power as you navigate or switch units.

Apropos switch units: who made the editor tab shifting almost useless?

IMO the scroll buttons should scroll the editor tabs by pages, not activate the next left/right tab.

DoDi

Zitat von Hans-Peter Diettrich :

I don't see how.
Find in files shows simple text and identifier occurences. Find in Files and Find identifier references already use the same window. Messages shows several types of messages from compiler, make, codetools and allows to quick fix these. It is planned to allow filtering and sorting.
Code observer shows places that might be interesting for code tools. It is planned to add a second treeview to the code explorer as gui for the codetools.
Code explorer has lots of short items (more height than width), the other two need more width than height.

I see no problem to page-dock messages and find in files, but implementation and usage are too different to marry them.

AFAIK merging menus is a very old Delphi feature.
There are some starts in the LCL already.

Wishlist:
http://wiki.lazarus.freepascal.org/Feature_Ideas

Mattias

Yes.I agree.+1 vote for Graeme :-)

In fact we see here old problem of two rights - both groups are right , partially.

While it would be nice to have as many nice features placed in one "Code explorer" as possible - that WILL double windows, because someone not using docking (due to limited free memory for example) will find faster to use Ctrl+F12 to show not bloated window with unit names then bloated code explorer.
So what would show Ctrl+F12 shortcut in such case ?

Boguslaw

2009/5/7 Bogus?aw Brandys :

Ctrl+F12 is a shortcut for "unit list", not "procedure list" Graeme was talking about.
To me, this confusion is yet another argument that number of windows should be reduced ;-)

I prefer the current way. I guess that depends on the number of units opened a once -- I usually try not to have too many.

1)
So when you say "reduce number of windows": Does that imply reduction of shortcuts too. Or will all the shortcuts be kept, and just switch to the correct tab (including open the window, if not yet open)?

2)
There also is an argument for not merging the windows. Someone might want to have both windows open, and see both lists at the same time. I don't use many of them, but it isn't totally unrealistic to assume that someone, might have unit and procedure windows both open? So once a unit was selected you can seltct procedures with no window switching. (Especially people who have 2 or more screens)

Zitat von Bogus?aw Brandys :

The code explorer has just starting to get interesting. I don't think it will become a quick search tool. More a gui for exploring and refactoring.

The code explorer does not eat much memory as it only shows the content of one unit.
I plan more tools like the code browser - that scans whole source trees and need two or three hundred megabytes. But these tools will not be invoked by default and they share the same memory.

So what would show Ctrl+F12 shortcut in such case ?

Mattias

I know ,it was only an example on not bloated window ;-)

Boguslaw

Unit Controls plus the *.inc files does not fit in one page, not to count further relations down into the widgetset. When I need the current project as well, I often have more than 20 files open at the same time. [this is only one argument against the use of include files, and for multiple editor windows ;-]

DoDi

I plan more tools like the code browser - that scans whole source trees and need two or three hundred megabytes. But these tools will not be invoked by default and they share the same memory.

The code explorer can be seen as the map in a master-detail view. Then the file list (editor tabs) also could be added to the code explorer.

Every (future) editor window should have its own code explorer.

BTW, the memory consumption should be a fraction of your estimate, because every node only contains the identifier name and a file reference and position.

DoDi

Pleas do not have docking in the UI!!! It might look cool bot it is a pain to use and program.

Windows accidentally un-dock and attach to your mouse then end up anywhere so you spend ages trying to get it back to how it was.

Much better to use frames to keep it looking how the developer intended. This is also easier to program as all you need to do is change the TForms to TFrames then build the main form at run time.

</div>

Dear Mr. Graeme Geldenhuys:

I read the documentation mentioned about gif, but really, I dont feel sure to do that.

I want to attach the "running leopard" in my applications. Its possible?

thanks in advance,

yours truly,

Ing. H?ctor F. Fiandor

---------------------------------------
Red Telematica de Salud - Cuba
CNICM - Infomed

To heat the discussion up:
From the wiki:

That would make debugging so much harder.
Let's assume merging those 3 does *not* mean a window with 3 tabs (as all 3 must be visible at once), but rather a window with splitters, so you can set how much of each you want to see...

1)
Still I often use watches to show local variables which have a very long value. In this case I can have a narrow Local window (left to the code), and a very wide (but only a few lines high / below the code) watches window.

Of course, If I am the only one who uses this in such a way, then it's not a reason.

2)
99% of the time I don't need the register window => with them all showing in the same window, I will be very busy hiding it (move the splitter to 0 size)

And I really can't imagine, that everyone else is using the registers at all times.

Martin

2009/5/6 H?ctor Fiandor Rosario :

I read the documentation mentioned about gif, but really, I dont feel sure to do that.

That is only meant for creating animated gifs for the wiki page - not for embedding them into your application.

I want to attach the "running leopard" in my applications. Its possible?

It sure is. I did something similar for fpGUI Toolkit, but didn't use animated gifs. Instead I use a composite bitmap. Say your animation is 4 frames. A composite bitmap then consists of 4 images next to each other making one wide image. The animation component then reads the single (wide) image, splits the large image into 4 small ones and simply display them one after the other in a loop with 200ms delay (or whatever the developer choses).

The animation component can be viewed using the following url. It should be very simple to port or rewrite this for Lazarus LCL.

http://fpgui.git.sourceforge.net/git/gitweb.cgi?p=fpgui;a=blob_plain;f=src/gui/fpg_animation.pas;hb=master

PS:
I don't think TImage supports animated gifs directly.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/5/6 H?ctor Fiandor Rosario :

I read the documentation mentioned about gif, but really, I dont feel sure to do that.

That is only meant for creating animated gifs for the wiki page - not for embedding them into your application.

I want to attach the "running leopard" in my applications. Its possible?

It sure is. I did something similar for fpGUI Toolkit, but didn't use animated gifs. Instead I use a composite bitmap. Say your animation is 4 frames. A composite bitmap then consists of 4 images next to each other making one wide image. The animation component then reads the single (wide) image, splits the large image into 4 small ones and simply display them one after the other in a loop with 200ms delay (or whatever the developer choses).

The animation component can be viewed using the following url. It should be very simple to port or rewrite this for Lazarus LCL.

http://fpgui.git.sourceforge.net/git/gitweb.cgi?p=fpgui;a=blob_plain;f=src/gui/fpg_animation.pas;hb=master

PS:
I don't think TImage supports animated gifs directly.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Pleas do not have docking in the UI!!! It might look cool bot it is a pain to use and program.

Program what?

Windows accidentally un-dock and attach to your mouse then end up anywhere so you spend ages trying to get it back to how it was.

This happens only with the bad Delphi defaults, where docking starts immediately. The Lazarus IDE can override that behaviour, as does the Delphi IDE.

DoDi

Actually, I meant a single list without any splitters, but with a filter to show/hide some values based both on "kind" (watch/local/register) and a substring.
Besides reducing the windows count, this will also allow those developers who actually need them all to see all interesting values at a glance.

Interesting, but I guess this is indeed rather rare case. What kind of long values do you watch?

Sure, the window should remember its configuration, and I agree that by default, Registers should be hidden.

Hi:

Micro Focus buys Borland Software for $75 million
http://www.infoworld.com/t/mergers-and-acquisitions/micro-focus-buys-borland-software-75-million-484

Embarcadero, Micro Focus...broken in pieces and sold.

What a sad end for a company that once had a great and revolutionary product.

Santiago A.

....
another thing with combining them, is that the amount of Locals keeps changing (watches just display unavailable).

This means that (unless locals are last in the list), everything keeps changing position, and you have to adjust where to look for it. (OT: Would be a great feature to bind watches to a stackframe, and have them changing automatically...)

Mainly structures/records/classes...
Of course that would be better solved, by having each member on a line of it's own.

You also have to find a way how to deal with different properties that watches can have (not yet, but in future: mem-dump, hex, dec, ... hust see the property window). In princible they can be applied to locals, as long as you can find a way to match them, each time locals had been updated. Because if you change stack frame you may have a local with the same name, but it is a different variable. So how to you bind those properties to a local value?
Not sure if those props make sense for registers....

Martin

Agree, thy should be the last.

(OT: Would be a great feature to bind watches to a stackframe, and have them changing automatically...)

+1

Agree.

Well, since the display format is per-value, this issue is totally orthogonal to the window consolidation. In fact, if display format is going to be controlled by e.g. context menu, then said consolidation might save some duplicated code.

Not sure if those props make sense for registers....

Well, dec/hex definitely do. I actually looked at registers at the first time during this discussion and was surprised that some values are in decimal